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-03-31 05:43 -------
I found out I also have to change the borrowObject method (as the following 
code), otherwise the expensive operation "_factory.activateObject(pair.value)" 
will still slow down the overall performance of the JDBC pool.

public Object borrowObject() throws Exception {

    long starttime = System.currentTimeMillis();

    for (;;) {
        ObjectTimestampPair pair = null;

        synchronized (this) {

            // if there are any sleeping, just grab one of those
            try {
                pair = (ObjectTimestampPair)(_pool.removeFirst());
            } catch (NoSuchElementException e) { /* ignored */
            }

            // otherwise
            if (null == pair) {

                // check if we can create one
                // (note we know that the num sleeping is 0, else we wouldn't 
be here)
                if ((_maxActive > 0) && (_numActive < _maxActive)) {
                    Object obj = _factory.makeObject();
                    pair = new ObjectTimestampPair(obj);
                } else {
                    // the pool is exhausted
                    switch (_whenExhaustedAction) {
                        case WHEN_EXHAUSTED_GROW:
                            Object obj = _factory.makeObject();
                            pair = new ObjectTimestampPair(obj);

                            break;

                        case WHEN_EXHAUSTED_FAIL:
                            throw new NoSuchElementException();

                        case WHEN_EXHAUSTED_BLOCK:
                            try {
                                if (_maxWait <= 0) {
                                    wait();
                                } else {
                                    wait(_maxWait);
                                }
                            } catch (InterruptedException e) {
                                // ignored
                            }

                            if ((_maxWait > 0)
                                    && ((System.currentTimeMillis() - 
starttime) >= _maxWait)) {
                                throw new NoSuchElementException("Timeout 
waiting for idle object");
                            } else {
                                continue;        // keep looping
                            }

                        default:
                            throw new IllegalArgumentException
("whenExhaustedAction "
                                    + _whenExhaustedAction + " not 
recognized.");
                    }
                }
            }

            _numActive++;
        }

        try {
            _factory.activateObject(pair.value);

            if (_testOnBorrow && !_factory.validateObject(pair.value)) {
                returnObject(pair.value);
            } else {
                return pair.value;
            }
        } catch (Exception e) {
            returnObject(pair.value);
        }
    }
}

As I turned off "testOnBorrow" and "testOnReturn", I didn't further 
investigate the potential impact of "_factory.validateObject" which may also 
be very expensive and is currently executed within the synchronized block.

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