commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: [pool][dbcp] Move AbandonedObjectPool in v 2's?
Date Fri, 20 Jul 2012 20:47:26 GMT
On 16/07/2012 20:55, Phil Steitz wrote:
> 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.

Sounds good. I was thinking that recording the stack trace could be an
option of GOP/GKOP. i.e. add [g|s]etLastUsed to PooledObject and add an
option to BaseObjectPoolConfig to record stack trace on borrow. What I
hadn't checked was what changes DBCP might require to maintain the
parent-child relationship.


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

View raw message