gsstark@mit.edu (Greg Stark) writes:
> Jan Wieck <JanWieck@Yahoo.com> writes:
>> Even applications that have statefull enduser terminals (like SAP R/3 for
>> example) never allow an open transaction over user interaction.
>
> I'm not sure using SAP as your paragon of design excellence is a
> wise choice here. From what I understand SAP implemented its own
> locking system because the database it was based on didn't offer any
> locking at all.
I don't think "design excellence" is the point; I'd point at Sabre/STS
as another example of "never an open transaction").
You (as a travel agent, out at the "client level") don't get to open
up user level transactions to the airline reservation system.
Instead, you fill a 3270 screen or some part thereof with data, and
then submit an "update."
As a result, each request is a fully-formed transaction, if a small
one.
> But your basic point is sound. For a web site I would definitely
> avoid using anything like database locks and even avoid doing
> anything with application locks if possible.
> If you really really want to expose the database session state I
> think he's on the right track using SQLRelay. This would let him
> handle reconnecting a user with her session even if she's connecting
> to a different Apache process.
We've got some web apps where it would be kind of nice to keep a
cursor around for a little while.
But there have been plenty of times when I have had to rue the fact of
transactions being held open for a long time by one thing or
another...
--
"cbbrowne","@","ca.afilias.info"
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)
