> I do not believe there is any fundamentally sound algorithm that a
> connection pool can use to detect when a connection has truly been
> "abandoned" and is thereby suitable for recovery.
If we did not have a pool, the server would eventually (a) run out of
connections, possibly impacting other applications in the system and/or (b)
timeout excessively old connections. Those timeouts are generally very
long. The default in MySQL is 8 hours.
The question to ask is the purpose of a connection pool. If it is to
improve performance, then it has a set of jobs. Changing the
characteristics of the preceeding paragraph are not included in that set of
jobs.
Where people want a connection pool to recover abandoned connections, that
usually points to either poor programming within a particular application,
or sharing by multiple application components, one of which may have a
problem. Essentially, they want to shorten the server timeout, so that
other components can't deny service by losing track of connections.
Do you concur with this analysis?
> It's really sad that people writing database driven software using a
> connection pool don't seem to be aware of how trivially simple it is to
> make sure that connection leaks do not happen to them, using a
> try/catch/finally block to ensure that the release always happens.
I agree. The code that I use is even more that what you posted, so much so
that it led me to develop a functor-type approach for our internal use,
where I provide the normative database operation(s) that we want performed,
and the core library manages the rest.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
