Re: [PDO] Question on Persistent PDO Connections
| From: | Lester Caine | Date: | Fri, 06 Nov 2009 07:56:18 +0000 |
| Subject: | Re: [PDO] Question on Persistent PDO Connections | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.pdo |
| Request: | Send a blank email to pdo+get-305@lists.php.net to get a copy of this message | ||
Lukas Kahwe Smith wrote:
While Firebird keeps the connections open ( and one has to make sure to shut down apache before doing any database maintenance ) it always completes a transaction in a current page either committing or if there is an outstanding error rolling back. Just to clarify terms here - what are you referring to by 'session'? I would not expect transactions to remain open from one page load to the next, but that seems to be what some people are asking for? Anything that needs to be persistent across page loads should be held either in the database or outside transactions? One can not run a multiuser system if someone is going to start a transaction but not finish it - perhaps due to loss of connection .... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.phpPDO has a way to detect whether a persistent call was made http://www.php.net/manual/en/pdo.getattribute.php, but there isn't going to be a PDO DB-portable way to tell whether the DB created the connection or reused it or reset etc. So my clear statement (tm) suggestion is "PHP shall not generically make any assummptions about the connection state of a new PDO connection, except that it will not have an open transaction. Some databases may have optimizations that allow global state information to be retained from a persistent connection in one script into another script. The safest practice is to assume that this state is not carried over and must be reset. Refer to the PDO_xxx driver documentation for database specific information".hmm yeah .. i guess it would be tricky, since generally i think we should aim to let the RDBMS clean up the session as good as possible if persistent connections are used.