Re: [PDO] Question on Persistent PDO Connections

Christopher Jones wrote:

Lester Caine wrote: Christopher Jones wrote:

Just to clarify terms here - what are you referring to by 'session'?

Here session refers to the resources used by the PHP connection. In OCI8, session & connection are pretty much synonymous. But if you had a multi-threaded mid-tier you could code an application to have multiple user sessions per physical DB connection. Fundamentally it's a way of resource sharing. The connection is a "pipe" to the DB and the session is the work being done across the pipe.

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

....

Transaction monitors traditionally allow external control of transaction state. In Oracle 11g this has been exposed through to a simple API which is fun: a DB transaction can span multiple HTTP requests. See

http://download.oracle.com/docs/cd/E11882_01/appdev.112/e10471/adfns_xa.htm#ADFNS802 What happens in this example where the suspended transaction is never completed? Sounds like a recipe for disaster to me ;) That why they call them "monitors". TPMs monitor the transaction state and resolve "in-doubt" transactions according to configured rules. This is the same as an e-commerce website having to decide when a shopping cart has been abandoned.

But in the case of the shopping cart, you would not leave it I a floating transaction. Depending on how you work, either you only confirm stock availability when the order is placed, or alternatively you 'pre-book' stock to ensure availability and then release it back when the 'basket' times out. Transactions should never be 'in-doubt' they are either active - or if orphaned they get rolled back. The shopping basket would be safely committed in a temporary table of some sort and stock availability managed against committed records. -- 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.php