commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <phil.ste...@gmail.com>
Subject Re: [pool] New DBCP deadlock reported (DBCP-44)
Date Sun, 02 Mar 2008 01:05:20 GMT
Thanks, Christoph

On Sat, Mar 1, 2008 at 4:21 AM, Christoph Kutzinski <kutzi@gmx.de> wrote:
> As the 'inversed' locking order in evict() is obviously the source of
>  the problems, I would try to avoid calling any _factory methods while
>  holding the 'this' lock.

+1
evict and addObject currently violate this and I think both should be fixed.

>
>  I thinking about something like this:
>
>  public void evict() {
>    CursorableLinkedList tmpPool;
>    Collection connsToEvict = new ArrayList();
>    synchronized(this) {
>      tmpPool = new CursorableLinkedList(_pool);
>    }
>
>    // checking for conns to evict, calling methods on _factory and adding
>    // conns to evict to connsToEvict
>
>    synchronized(this) {
>      // remove conns in connsToEvict from _pool
>      // ignoring conns that are (currently) not in pool
>    }
>   }
>
>  Obviuosly, this doesn't work with the evictionCursor as it is
>  implemented now, so it would require some work on that one.
>

I think something like this might work if we can solve:
1)  Maintaining the cycling behavior of the evictionCursor -  will be
tricky, but should be doable.  2)  "ignoring conns that are
(currently) not in pool" in the second synch block - hard to do
efficiently, but again should be doable
3) when to do _factory.destroyObject - can't do this is the
mid-section because borrowObject could jump in and grab the destroyed
object.  Need some way to prevent that, maybe by locking / marking the
ObjectTimeStampPair.

Phil

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


Mime
View raw message