Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: 11 May 2003 14:38:14 -0000
Message-ID: <20030511143814.9438.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: commons-dev@jakarta.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 16987]  -
    race condition in PoolableConnection.close()

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=16987>.
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=16987

race condition in PoolableConnection.close()


------- Additional Comments From dirk.verbeeck@pandora.be  2003-05-11 14:38 -------
My 2 solutions for the race condition 
(the no-op double close should be a different bugzilla entry IMHO)

Solution 1:
------------
The race condition can be solved by using a pool that doesn't allow an object to
be returned in it twice. Subclassing GenericObjectPool will do the trick.
Changing the returnObject method in the following way will solve the problem.
Synchronizing on the returned object itself should be enough but _pool.contains
should be checked for thread safety. Maybe another _pool collection
implementation should be chosen. (for threading and/or speed)

public void returnObject(Object obj) throws Exception {
    assertOpen();
    synchronized(obj) {
        if (_pool.contains(obj)) {
            // do not returnObject to the pool when it is already in it
            return;
        }
        boolean success = true;
...

Solution 2:
------------
PoolableConnection:
    synchronized public void close() throws SQLException {

This seems to be the the simplest solution, the _closed attribute is on the
connection object itself and doesn't depend on the pool for changing it's state
so I don't think a synchronization on the pool is needed.
Maybe I'm overlooking something but I can't find any deadlock problems with this
solution.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org