Actually, now that I'm more awake, I think the idea of a thread "timing out" borrowed connections is a bad thing. -- It adds more code to DBCP, and adds the overhead of an extra thread. To top that off, its only purpose in life is to work around code problems, rather than fixing them.
With the other features there to show you exactly where you have holes in your code, it's real easy to identify and fix them, while this feature just discourages doing something about those holes. James At 2/23/2002 08:40 PM -0700, you wrote: >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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
