commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Smuts" <aaron.smu...@verizon.net>
Subject RE: commons dbcp or pool problems
Date Tue, 26 Feb 2002 06:32:34 GMT
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:james_strachan@yahoo.co.uk]
> 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" <glenn@voyager.apg.more.net>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> 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:commons-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
> >
> > --
> >
----------------------------------------------------------------------
> > Glenn Nielsen             glenn@more.net | /* Spelin donut madder
|
> > MOREnet System Programming               |  * if iz ina coment.
|
> > Missouri Research and Education Network  |  */
|
> >
----------------------------------------------------------------------
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-
> help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message