On Fri, 10 Jan 2003 18:37:52 +0100
Csaba Nagy <nagy@domeus.de> wrote:
> AFAIK Using the same connection to do more queries at the same time is
> not supported by the backend.
> If you use transactions, it will only make your life harder to make
> sure the transaction goes on on the same connection, and nobody else
> uses the same connection meanwhile, messing with your ongoing
> transaction... unless the postgres developers would be willing to
> implement connection independent transactions (by the means of a
> transaction ID passed along with the query ? this is DB sience fiction
> - might be good but it's not standard nor really needed).
>
By using something like virtual (or "soft") connections (see my
previous post) it's relatively straight forward to make sure that
several queries that form a single transaction get the same DB
connection. Once a transaction is started on a virtual connection
and the VC gets a hold of a database connection it can
simply hold on to it until the transaction is finalized. If another
virtual connection is waiting for a DB connection it will just
queue its queries and wait for one to become available. Once it gets
it, it will hold it for the duration of one query (for non TX queries)
or several queries (eg, "BEGIN", "INSERT..", "UPDATE..", "COMMIT").
> I assume your problems with connection pooling are the relatively big
> setup time of a connection, and the possibility of running out of
> connections...
I think the more pressing problem for the connection-pooled,
event-driven server is that it cannot block to wait for a connection
(for whatever reason). At the same time it's pretty cumbersome for an
application developer to have to manually queue queries during the
wait.
Regards,
Iker
