NTPT wrote:
> 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
You've just reinvented connections. The problem is at the application
end really, since PHP doesn't provide a middle-ware layer to manage this
sort of stuff. Typically, java-based application servers manage this
sort of thing for you.
> 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 )
Perhaps take a look at pgpool connection pooling.
--
Richard Huxton
Archonet Ltd