Re: Database Pooling

[do...@idealx.com]

> 
> Well, it's going to be a pretty strange environment that doesn't have a 
> database connection in every process.

Sure. And beware of connections that are returned to the pool without
being rollbacked, too - the app then deadlocks itself because it holds
locks in the database and doesn't know it does. I get bitten by this
under JDBC every so often, when an exception is thrown at the wrong
time.

>From the app perspective, I tend to prefer viewing database
connections as singletons rather than pooled objects. This avoids lots
of problems like the two above, and enables fancy extensions. For
example I can simulate nested transactions even on databases that do
not support them: I can say "If a transaction is open in the (unique)
database connection we have, don't start a new one and just up the
(app-internal) nesting counter".

-- 
Dominique QUATRAVAUX                           Ingénieur développeur senior
01 44 42 00 35                                 IDEALX

Re: Database Pooling

[do...@idealx.com]

> Sounds like you should have some more code in your finally
> blocks. :)

Well I don't quite like having to do that everywhere, especially in
code I did not write. In Perl I only need one of them using some
AUTOLOAD trickery :-).


-- 
Dominique QUATRAVAUX                           Ingénieur développeur senior
01 44 42 00 35                                 IDEALX

Re: Database Pooling

[Kenny Smith <ke...@journalscape.com>]

> Sure. And beware of connections that are returned to the pool without
> being rollbacked, too - the app then deadlocks itself because it holds
> locks in the database and doesn't know it does. I get bitten by this
> under JDBC every so often, when an exception is thrown at the wrong
> time.


Sounds like you should have some more code in your finally blocks. :)

KS