Re: Connection Pooling, a year later

Bruce Momjian wrote:


> Seems like a lot of work to keep track of transaction state in the
> client;  seems easier to just unconditionally issue the begin;rollback.


Well, in the Oracle and PG drivers for AOLserver it wasn't, but then 
again applications code in that environment doesn't call libpq directly 
but through an abstraction layer that works with all DBs (the layer 
does, the query strings obviously sometimes don't!).  The db primitives 
then call an RDBMS-specific driver, which can call thread-safe RDMBS 
client libraries directly or call an external driver (possibly the 
external ODBC driver) for RDBMS's without a thread-safe client library.

So we can track things easily.  Along with other things, for instance 
retrying queries in one backend after another backend has bombed out and 
given the nice little message saying "another backend has closed, please 
retry your query".  Luckily it was pretty easy to kill PG 6.5 so I could 
test and debug this feature...

I suspect that major applications that support multiple RDBMS's take a 
somewhat similar approach.  In the context of providing an abstract 
database API for one's client code, adding persistent connection pooling 
seems pretty minor.

-- 
Don Baccus
Portland, OR
http://donb.photo.net, http://birdnotes.net, http://openacs.org