commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ken Horn" <>
Subject Re: DBCP status?
Date Mon, 30 Jun 2003 08:54:08 GMT

I'm in the "don't reclaim" camp, but am thinking, IF somebody really wants it, then the solution
would be to rollback and close the real connection -- this:
* emulates a legal timeout from the database server
* ensures any further action on by the rogue app will get a suitable exception
* provides database side cleanup as a failure condition
* won't impact performance of the pool, since the connection timeout is bound (?) to be way
higher than the overhead of opening a new connection.

I think this would alleviate much of the force-back-to-the-pool angst - force it to be closed
for proper clean up while not hogging resources

                      Anton Tagunov                                                      
                      <        To:       "Jakarta Commons Developers List"
            >                    cc:                                    
                                               Subject:  Re[2]: DBCP status?             
                      30/06/2003 07:31                                                   
                      Please respond to                                                  
                      "Jakarta Commons                                                   
                      Developers List"                                                   

Hi, All!

1) A side-note

It would be really more easy if this discussion was
held somewhere on db-commons, really :-)


PS> The EAI or network infrastructure, for example, behind one of the
PS> apps could cause it to grind to a halt, effectively orphaning any
PS> connections that it has open, depriving the other apps of these
PS> resources.

Hey, there's one more solution!

So far we have discussed two possible actions if a connection
has not been returned to a pool too long:

a) just log it as an error and do nothing
b) forcibly bring it back to the pool

But we can have c) here:

c) log this as an error and no longer consider the connection
   as part of the pool!

   That is, if
   * the pool is configured to have 10 connections max
   * our "too long not returned" time out is configured to be 60 seconds
   * all 10 connections have been taken out
   * one of them has not been returned for over 60 seconds

   We just "forget" about the "too long not returned" connection
   and consider that our pool now has only 9 connections.
   This allows us to create one new connection and give it
   to the waiting clients.

   If afterwards the offending connection is returned after all
   there are two ways IMO to handle it
   i)  not put back to pull at all, just close it uncoditionally
   ii) see how many connections we have in the pool, if we have
       bellow 10, add it to the pool, if we have all 10 already,
       close it as being excessive

   This solution leaves the abandoned connections to be reclaimed
   but the regular database timeout (8 hours for the standard
   MySQL setup) which is not that bad.

   This of course won't work too well if the database limits
   the number of connections available to, say 10, by the license,
   but I propose the following criteria:

   The situation when the pool is applied shouldn't be worse
   then it would be if we had no pool.

   Of course if maxActive is non-zero this criteria is not obeyed
   anyway, so my solution best applies if maxActive is 0.

   What to do if maxActive is positive I'm at a loss

- Anton

P.S. The following note by David Graham probably makes
this behavior unnecessary, still I wanted to propose it.

DG> If your environment has the above characteristics, each
DG> application would have its own separate connection pool
DG> so a failure in one app would not affect another.

To unsubscribe, e-mail:
For additional commands, e-mail:


This e-mail may contain confidential and/or privileged information. If you are not the intended
recipient (or have received this e-mail in error) please notify the sender immediately and
destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message