commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [pool][dbcp] Move AbandonedObjectPool in v 2's?
Date Mon, 16 Jul 2012 19:55:19 GMT
On 7/15/12 10:46 AM, Phil Steitz wrote:
> On 7/15/12 1:12 AM, Mark Thomas wrote:
>> On 15/07/2012 01:38, Phil Steitz wrote:
>>> Sorry if this has been discussed already and I can't find the
>>> thread; but we should do this now if we want to do it - i.e., move
>>> DBCP's AbandonedObjectPool into [pool].
>> This is certainly something that - on the face of it - makes sense.
>> However, when I looked at it a little while back it did not appear to be
>> trivial to unpick the AbandonedObjectPool code from DBCP.
>> I didn't spend enough time on it to come to a final conclusion.
>> I can look at this in the next week or so. It would be helpful if other
>> folks looked as well.
> I just dug into this a little and it looks like just moving the
> classes and adjusting imports will work.  I had to increase
> visibility of addTrace, removeTrace, get/setLastUsed in
> AbandonedTrace; but other than that I did not have to make any
> changes.  If others are OK with this, I will open a JIRA for this
> (maybe one for each of DBCP, POOL?), continue testing, cleanup the
> docs and get the changes committed assuming I don't run into any
> problems.  Fortunately, the original design looks like it intended /
> anticipated this move.

OK, I have pretty much verified that this can work, but I am now
asking myself if with the new GOP that holds references to checked
out objects, do we need such a heavyweight approach?  If we just
extend PoolableObject to something like TrackablePoolableObject
adding set/getLastUsed, the new GOP (extended) could do this
directly (without adding the trace list).   The only loss would be
stack trace generation, which we could continue to provide in an
abstract class implementing the new interface.  The AbandonedTrace
machinery in DBCP conflates trackability with maintaining
parent/child relationships, which it could continue to do - i.e.,
leave AbandonedTrace in DBCP, implementing TrackablePoolableObject
and perhaps inheriting from the abstract parent that supports stack
trace generation.

> Phil
>> Mark
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

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

View raw message