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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
