commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christoph Kutzinski" <ku...@gmx.de>
Subject Re: [pool] New DBCP deadlock reported (DBCP-44)
Date Wed, 05 Mar 2008 08:51:01 GMT

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

Uhm, no it can't work. I see it this way: we have to check from either side, if the object
was not concurrently marked by the other side. I.e. in borrowObject one has to check if the
object is not currently being validated and only then may mark it as being borrowed. And vice
versa for the evict method. Without synchronization or CAS this cannot work, being volatile
alone is not enough.
Unless I missed something of course and you have a much smarter solution :)

greetings
Christoph

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


Mime
View raw message