To: Jan Wieck <JanWieck@Yahoo.com>
Cc: =?iso-8859-1?q?Jens_Lechtenb=F6rger?= <lechtej@uni-muenster.de>,
	pgsql-interfaces@postgresql.org
Subject: Re: Lost updates vs resumable connections/transactions
References: <Pine.A41.4.58.0412091641060.68588@zivunix.uni-muenster.de>
	<41C06961.8020406@Yahoo.com>
In-Reply-To: <41C06961.8020406@Yahoo.com>
From: Greg Stark <gsstark@mit.edu>
Organization: The Emacs Conspiracy; member since 1992
Date: 15 Dec 2004 14:43:41 -0500
Message-ID: <87is73qrde.fsf@stark.xeocode.com>
Lines: 24
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


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.

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.

I suspect the database wouldn't really be able to suspend a database
connection using any less memory than just keeping the entire backend process
with its session around anyways.

-- 
greg