From: | "NTPT" <ntpt(at)seznam(dot)cz> |
---|---|
To: | "Postgres General" <pgsql-general(at)postgresql(dot)org> |
Subject: | More concurent transaction over single connection ? |
Date: | 2005-02-08 23:22:44 |
Message-ID: | 002201c50e35$18171a70$7400a8c0@wbp1 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
AFAIK (7.4.x) there is one limitation in persistant connections to
postgresql from various frontends (
http://cz.php.net/manual/en/features.persistent-connections.php ), because
it can not use transactions in situation where more concurent tasks use a
single connection (execuse my wrong english)
I suggest to add some sort of "context" identificator to frontend/backend
protocol to overcome this limit. Ie frontend - ( like PHP for example )
make ONE persistant connection and different scripts are served over this
connection. But frontend add for each instance of script a unique "context"
identificator and postgresql server will treat different "contexts" as
they was send by different connections. The results wil be sorted by
"context" by frontend and feeded to apprpriate instance of the php script
I think it may add some benefit to avoiding connection starting costs,
especially in case where database and client are in greater network distance
and/or need to use some expensive procedure to start connection and allow a
relay simple and transparent connection pooling, may be a some type od
"spare servers" like in Apache (MinSpareServers and Max SpareServers
configuration directive )
What do you think about it ?
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2005-02-08 23:24:12 | Re: PL/pgSQL bug: FOUND variable is not updated correct |
Previous Message | Tom Lane | 2005-02-08 23:11:10 | Re: PL/pgSQL bug: FOUND variable is not updated correct with EXECUTE |