Actually, I had it working that way for a while too, but had complaints (in-house) about the extra thread... But I'd be happy to throw it in.
I guess the question is: Should this be in the standard DBCP stuff (with an on-off switch) or as separate classes only for use during debugging? James At 2/23/2002 08:11 PM -0600, you wrote: >I like this. There is another option which could be added. > >clientTimeout > >It the pool exhausts its connections, it will review the list >of connections in use, the connection which exceeds the clientTimeout >by the most gets recycled. If all the Statements are tracked, >they can be closed (which closes any open result sets for those Statements). >And then the Connection can be closed. A new connection would need >to be created to replace the one recycled, then the old connection >and Statement could get GC'd. > >This would help prevent those cases where a poorly written JSP page >or Servlet doesn't close and release its JDBC resources from preventing >others from getting a JDBC connection. > >Logging of misbehaving JSP pages and servlets is important. > >I am all for adding the below patch and the option above. > >It sure would have saved me some time the last few days. :-) > >Regards, > >Glenn > >James House wrote: > > > > At 2/23/2002 01:25 PM -0600, Rodney Waldhoff wrote: > > > > A few months back I made my own hacks to > > > > DBCP in order to have it find places in > > > > our code that didn't free up DB resources > > > > properly. > > > > > > > > I was able to generate class names and > > > > line-numbers (stack trace) for every place > > > > in the code that a statement or result set > > > > was created but never closed, and also able > > > > to track where connections were borrowed > > > > and never returned. > > > > > > > If anyone's interested, I could try > > > > digging it up, and posting it. > > > > > >Sounds great, especially if we can do it relatively unobtrusively (or > > >optionally). By all means, put together a patch. > > > > I'll be happy to put together a patch. > > > > First let me know what the preference is of how it fits in: > > > > Background: > > > > The changes affect the following classes: > > > > PoolableConnection > > PoolableConnectionFactory > > PoolingDataSource > > DelegatingStatement > > DelegatingResultSet > > DelegatingPreparedStatement > > DelegatingCallableStatement > > > > The changes basically entail adding Lists to the objects to keep track of > > the sub-objects that they've made, and also adding a member variable that > > hold a reference to an Exception that is created (but not thrown) at the > > time the Connection was borrowed or at the time a Statement / ResultSet > > was made... so that it can be used to generate a stack trace that shows the > > code that borrowed/created the resource, when we detect that it wasn't > > closed/returned properly. This detection is done by removing the objects > > from the before mentioned lists as close() is called on them, and then > > checking if there are still objects in the lists when the connection is > > returned to the pool, or by calling a new method "detectLeaks()" on > > PoolingDataSource to find un-returned connections. > > > > So you can see the changes aren't extremely intrusive (as far as changing > > existing code) but do ADD roughly 10 - 35 lines of code to each of the > > classes listed above. > > > > Option One: > > > > Create a patch that alters these classes, and allows you to turn on/off the > > debugging features at the time you create your instance of > > PoolableConnectionFactory. > > > > Option Two: > > > > Create new versions of these classes that have the feature always on, and > > you simply use a class named something like > > "DebugPoolableConnectionFactory" instead of "PoolableConnectionFactory" as > > you create your datasource. > > > > Also, I submitted a couple suggested patches back on January 17th (2 > > separate e-mails to this mail list with the subject starting with [DBCP]), > > but never heard any response - albeit I didn't submit formal patches. > > > > I'd be happy to create these patches at the same time if you agree with > them. > > > > James > > > > -- > > To unsubscribe, > e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > >-- >---------------------------------------------------------------------- >Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder | >MOREnet System Programming | * if iz ina coment. | >Missouri Research and Education Network | */ | >---------------------------------------------------------------------- > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
