"Guy Rouillier" <guyr@xxxxxxxxxxx> writes:
> Having worked with web-based, transaction-oriented applications for
> almost 10 years now, I don't see any justification for holding an actual
> database transaction open between HTTP requests. As Tom correctly
> points out, there is no guarantee whatsoever that the end user will ever
> complete such a transaction.
Indeed I've never needed them either. But then I've never worked on a banking
system or an airline ticket reservations system, or anything that would need
anything but the simplest of transactions. So I've always found a way to
finesse the issue and avoid entirely the entire field of having to deal with
expiring sessions and conflict resolution.
But the fact that these problems exist don't militate for either database
transactions or an application level reimplementation of transactions. In
either case you'll have to deal with expiring and rolling back old
transactions and with resolving conflicts.
I take it as a given that if suspended transactions were ever to appear people
would expect a system table that let them list suspended transactions and how
when they were suspended. Otherwise they just wouldn't be very manageable.
--
greg
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
