You can easily take out Oracle this way, even by just not closing statements on reaped connections. This is very dangerous.
I have a *practically* fool proof pooling technique that we are working on. I may have something in a few days. To sort of give it away -- we clean up after each request. Guess how. I may have already mentioned it. The programmers don't even have to release their resources after getting a connection from the pool. It isn't limited to servlets either. A friend came up with the technique. I love it. Even with a background reaper a single bad class can take out your database under high load. I've seen it happen. It just isn't good enough. If your project gets large enough, you may never find all the possible problem areas. Does the pool you are working on work with JDK1.4 and 1.3? Aaron > -----Original Message----- > From: James Strachan [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 25, 2002 7:02 PM > To: Jakarta Commons Developers List > Subject: Re: commons dbcp or pool problems > > Why not just create more connections when the pool is exhausted and then > log > a warning message, so the bug can be tracked down later without breaking > production? Most databases can handle plenty of connections these days > anyways. > > James > ----- Original Message ----- > From: "Glenn Nielsen" <[EMAIL PROTECTED]> > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> > Sent: Sunday, February 24, 2002 2:11 AM > Subject: Re: commons dbcp or pool problems > > > > 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:commons-dev- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:commons-dev- > [EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
