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

Re: Lost updates vs resumable connections/transactions

From: Jens Lechtenboerger <lechten(at)wi(dot)uni-muenster(dot)de>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Lost updates vs resumable connections/transactions
Date: 2004-12-16 13:52:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces
Greg Stark <gsstark(at)mit(dot)edu> 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.
> 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.

Well, I don't necessarily have to use locks.  I want any form of
concurrency control that ensures serializability.  Optimistic
approaches would be fine as well.

> 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.

But why should I have SQLRelay between me and the database?
I don't plan to use any of its "real" features.  It would just be a
proxy with a known address that maintains a database connection.
Obviously, the database server itself has a known address and
maintains database connections...


In response to


pgsql-interfaces by date

Next:From: Greg StarkDate: 2004-12-16 18:05:22
Subject: Re: Lost updates vs resumable connections/transactions
Previous:From: Christopher BrowneDate: 2004-12-15 21:22:49
Subject: Re: Lost updates vs resumable connections/transactions

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