DO NOT REPLY [Bug 7519] - The DBCP has a sloggy performance under a multi-thread environment

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7519>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7519

The DBCP has a sloggy performance under a multi-thread environment





------- Additional Comments From [EMAIL PROTECTED]  2002-04-03 13:02 -------
This patch violates the org.apache.commons.pool.PoolableObjectFactory contract, 
which states that validateObject will only be invoked on an "activated" 
instance.  (So we can't call passivateObject and then validateObject, it needs 
to happen the other way around.)

Your concern is to move the passivateObject call out of the syncronized block, 
yes?  Perhaps we should just move all the factory calls out, like this:

    public void returnObject(Object obj) throws Exception {
        boolean success = true;
        if(_testOnReturn &&  !(_factory.validateObject(obj))) {
          success = false;
          try {
             _factory.destroyObject(obj);            
          } catch (Exception e) {
             // ignored?
          }
        } else {
          try {
             _factory.passivateObject(obj);
          } catch (Exception e) {
             success = false;
          }
        }

        boolean shouldDestroy = false;
        synchronized (this) {
            _numActive--;
            if ((_maxIdle > 0) && (_pool.size() >= _maxIdle)) {
                shouldDestroy = true;
            } else if (success) {
                _pool.addFirst(new ObjectTimestampPair(obj));
            }
            notifyAll(); // _numActive has changed
        }

        if(shouldDestroy) {
          try {
             _factory.destroyObject(obj);            
          } catch (Exception e) {
             // ignored?
          }
        }
    }

Does that have the performance you expect?

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>