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