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