Re: More concurent transaction over single connection

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