Skip site navigation (1) Skip section navigation (2)

Re: Lost updates vs resumable connections/transactions

From: Christopher Browne <cbbrowne(at)ca(dot)afilias(dot)info>
To: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Lost updates vs resumable connections/transactions
Date: 2004-12-15 21:22:49
Message-ID: 60ekhrdzo6.fsf@dba2.int.libertyrms.com (view raw or flat)
Thread:
Lists: pgsql-interfaces
gsstark(at)mit(dot)edu (Greg Stark) writes:
> Jan Wieck <JanWieck(at)Yahoo(dot)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)

In response to

pgsql-interfaces by date

Next:From: Jens LechtenboergerDate: 2004-12-16 13:52:49
Subject: Re: Lost updates vs resumable connections/transactions
Previous:From: Jens LechtenboergerDate: 2004-12-15 19:57:48
Subject: Re: Lost updates vs resumable connections/transactions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group