On Tue, 28 May 2002, Eckhard Hoeffner wrote:
> * Marco Colombo <marco@xxxxxx> [28 05 02 17:32]:
> >AFAIK, a CURSOR may be used only inside a single transaction, not a
> >single session. So it can't be used to 'page' the output of a query,
> >for example.
> >
> >And, also AFAIK, even with pconnect, each connect creates a different
> >session. Only the (TCP) connection is re-used. I mean, nothing changes
> >from the PHP script standpoint when you switch from pg_connect() to
> >pg_pconnect().
>
> I think, you are right. The connection browser<->web server is cut
> after the web server has send all TCP/IP-packages, no matter how
> long it takes till they are received on the client side (browser).
> If there ist a request for a new database connection, the web server
> does not know whether this is the former user or a new user. For
> this reason the result I wanted to acchive is not possible.
Well, with HTTP keepalive, it may even keep the HTTP session open.
But the problem is that you can't relay on it.
Moreover, I suspect that PHP resets the SQL session when it performs
an pconnect (that means, it asks the SQL backend to abort uncommitted
transactions, drop TEMP relations, and so on).
And, no matter what is the actual behaviour, the docs are clear:
"An important summary. Persistent connections were designed to have
one-to-one mapping to regular connections. That means that you should
always be able to replace persistent connections with non-persistent
connections, and it won't change the way your script behaves. It may
(and probably will) change the efficiency of the script, but not its
behavior!"
so even if it worked, it's an undocumented feature... well, it's a bug,
really. pconnect() is *documented* to have no side effects. B-)
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@xxxxxx
