commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Kutzinski <>
Subject Re: [pool] New DBCP deadlock reported (DBCP-44)
Date Tue, 04 Mar 2008 22:10:49 GMT
Phil Steitz wrote:

>>  > 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.
>>  That could be done after the second synchronized block, if we remember
>>  only the successful removed objects in connsToEvict (i.e. removing the
>>  ones which couldn't be removed from _pool)
>>  But that have made me think about a (probably) major flaw in this approach:
>>  It is probably not ok to access a pooled object from within the evictor
>>  thread while it is possibly concurrently accessed from a thread which
>>  borrowed it from the pool (and AFAIS we cannot prevent this scenario
>>  with this approach).
>>  So I also thought about marking the ObjectTimeStampPair as either being
>>  currently 'inEviction' or 'borrowed' or both (volatile boolean fields in
>>  ObjectTimeStampPair). But I fear that this would be vulnerable to
>>  various race conditions.
> What race conditions, exactly?

I was thinking to naive. I thought about e.g. getting an object from 
_pool, checking if inEviction is false and then setting borrowed to 
true. That would be of course vulnerable to race conditions.
But your approach with a single int status field and compareAndSet 
operations to update the status should be safe.

> Not having thought this through all the way, I was thinking about an
> integer property that could take one of four values
> "BORROWED" - a ghost in the pool snapshot
> "IDLE"  - in the pool, OK to borrow
> "DEAD" - in the pool, marked for eviction
> "VALIDATING" - in the pool, being validated
> If we need to synchronize, similarly to AtomicInteger, we could define
> a synchronized compareAndSet method that borrowObject, returnObject,
> and evict could use to control access.  Synchronization would, as you
> point out, cost something, but there should not be much contention for
> these locks.  I need to work through the various race conditions,
> though, to convince myself that a volatile field properly managed
> would not suffice.

Maybe a single volatile boolean could work. I'm not sure either.
I don't think that a volatile int field would work as you never could 
assure - without synchronization - that updates to that field are not 
executed out of order.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message