commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Tagunov <atagu...@mail.cnt.ru>
Subject Re[2]: DBCP status?
Date Mon, 30 Jun 2003 06:31:47 GMT
Hi, All!

1) A side-note

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

2)

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message