Actually, you can't be sure. It is quite possible to build a system in PHP that will behave in unwanted ways if you leave transactions open across accesses. Apache is stateless, with a thing layer of semi-statefullness layered on top like butter. This is the keep alive system, which is a stock part of the http 1.1 spec. What happens is that when a user accesses a web page, a certain apache backend gets associated to it for a short period of time. The problem with keep alive is that apache has a short attention span, since the default timeout for keep alives is 15 seconds. Let's say user A opens a web page with a form, and edits it for 3 minutes. His keep alive connection is gone. While it is still very likely that his next request will be serviced by the same child as the last time, there is NOT guarantee. Even if the user does make the changes before the timeout, or you crank up the timeout to something huge like 30 minutes, they still aren't guaranteed to get their own child process back, as if someone requested access and all the other children are now tied up in keep alives or active requests, the apache server throws the pid of all the kept alive and waiting requests and randomly grabs one to service the request. Poof, keep alive gone, not the same connection. So, you can't count on always getting your old transaction back. What you can do is rollback at the beginning of each script to make sure you're in "clean space" transactionally. For a read only type setup, where you're tossing a cursor around, you might be able to check for the existence of one, but I don't know how. On Sun, 18 May 2003, Raphael Bauduin wrote: > A related mail I tried to post on the list yesterday but that I got > back.... > > when inserting a record in a PHP script, I sometimes use the currval > function on the corresponding sequence to get the id of the row > inserted. > > Maybe a stupid question, but I wondered if when using persisten > connection, I could be sure there would be no problem. From the doc, > currval "Returns the value most recently obtained by nextval for this > sequence in the current server process." > > Can you confirm me several script using the same persistent connection > in parallel are in separate server processes? > > Thanks. > > Raph > > > > On Sat, May 17, 2003 at 11:53:44AM -0700, David Busby wrote: > > List, > > I cannot tell from the documentation if pg_pconnect() or pg_connect() > > are really different in how the connection pool is managed. Does anyone > > know if that is the case? Seems that using pg_pconnect would dictate "use a > > pooled connection" and pg_connect is "use a pooled connection, or make a new > > one". On "live" apps which is better to use, seems pg_pconnect. Thoughts? > > > > David Busby > > Systems Engineer > > busby@xxxxxxxx > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 4: Don't 'kill -9' the postmaster > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
