Most pooling is in essense a form of multiplexing. For transactions this can
be a bad thing.
10 connections -> pooler -> 2 worker connections
Incoming connection #1 (I1) issues BEGIN WORK
I1 statement passed to outgoing #1 -> O1
I2 and I3 statements flow through to -> O2
I4 statement UPDATE Row_never_to_be_rolled_back_ever goes through -> O1
I1 issues rollback -> O1
I4 statement rolledback along with I1 statements...
By only allowing a switch on commits, you avoid this (multiplexing against
transaction commits). There's probably a proper term for this. Send away
didn't know libdbi did pooling, otherwise they look like they have a nice
thing going.
AZ
> -----Original Message-----
> From: Mark Pritchard [mailto:mark@tangent.net.au]
> Sent: Tuesday, August 07, 2001 6:50 PM
> To: August Zajonc; pgsql-hackers@postgresql.org
> Subject: RE: [HACKERS] Client Side Connection Pooling
>
>
> > Curious if anyone has done any work on client side connection pooling
> > recently? I'm thinking pooling multiplexed against transaction
> > commits?
>
> I did some work on an abstracted DB API (supports PostgreSQL, Oracle and
> MySQL natively), with pooling and auto reconnect which I'd be
> happy to send
> you / post here.
>
> Alternatively, you can take advantage of libdbi, which I wish I had known
> about, say 2 months earlier :)
>
> http://libdbi.sourceforge.net/docs/
>
> btw - what on earth does "multiplexed against transaction
> commits" mean? The
> definition on dictionary.com suggests you may mean a transaction
> commit may
> return multiple connections to the pool? I really have no idea
> what you mean
> :)
>
> Cheers,
>
>
> Mark Pritchard
>
>