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
<[EMAIL PROTECTED] To: "Jakarta Commons Developers
List" <[EMAIL PROTECTED]>
t.ru> 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 :-)
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
