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