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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
