Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of kutzi@gmx.de designates
 213.165.64.20 as permitted sender)
Message-ID: <47CDC8E9.9010105@gmx.de>
Date: Tue, 04 Mar 2008 23:10:49 +0100
From: Christoph Kutzinski <kutzi@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: Jakarta Commons Developers List <dev@commons.apache.org>
Subject: Re: [pool] New DBCP deadlock reported (DBCP-44)
References: <8a81b4af0802290513r2199b2c8v4c94b8e691e8743f@mail.gmail.com>
	 <47C93C1E.7030309@gmx.de>
	 <8a81b4af0803011705t40aed931t248dbbd9e2882761@mail.gmail.com>
	 <47CAA6FC.20801@gmx.de>
 <8a81b4af0803022235r14deed0bo75c58c689ae586c0@mail.gmail.com>
In-Reply-To: <8a81b4af0803022235r14deed0bo75c58c689ae586c0@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

greetings
Christoph


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