Serge et al,
Further to my suggestion about using the Observer pattern for event notification w.r.t. point 4 (below) I forgot to mention that it also has the benefit of offering a compromise in the pro/anti recovery debate.
Existing contentious code designed to reclaim or test connections need not be retired as it could still be made available re-factored into a listener, and attached at runtime by the user. Users can use, extend or ignore DBCP's own listeners at their discretion shifting the decision from the developers to the users where, judging by the debate, it probably belongs.
I don't have a vote in DBCP... Using the Observer pattern seems a fine approach, especially since
the functionality was Voted on some time ago. Further, it sounds like you have tried to take others
concerns into account, and discussed the issue.
My 2 cents,
It also follows that DBCP need not then impose a single Jakarta-approved strategy, but could easily be shipped with a number of implementations of different strategies, chosen between and attached at runtime by the user or by DBCP itself in response to configuration settings.
4. Provide some kind of extensible connection object that could allow
someone to add their own (possibly included but optional) way to recover
abandoned connections.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Rob Leland
