Thanks, Christoph
On Sat, Mar 1, 2008 at 4:21 AM, Christoph Kutzinski <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
