Comments intermixed below. Juozas Baliuka wrote: > > Hi, > You can implement this without any extra thread. Pooling doesn't need > threads, but amost all > pool and cashe implementations use extra threads( it does nothing > meaningful). > Idea to use "timeout" is not very good, only crapy application needs this, I > think it is > good to have it for debug, but in this situation pool must fail and report > error, not > to try "find solution". > > > > > 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. > >
Timing out and recovering borrowed connections doesn't have to require another thread. Just recover a connection which has timed out by the longest _if_ the pool of connections is exhausted. > > 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. > > Logging those applications which do not release their resources is important. And it would allow me to strongly encourage customers to fix their code before it causes a problem. But in a production environment where I host the applications, not write them, I don't want to be called at 2PM on a Sunday to reboot the app server if a customer's application stops working because their bad code exhausted their db connection pool. I really think this feature is important. If you don't need it, don't enable it. > > 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 > > >> > ---------------------------------------------------------------------- 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]>
