Message-ID: <41C31A2E.9030107@Yahoo.com>
Date: Fri, 17 Dec 2004 12:41:02 -0500
From: Jan Wieck <JanWieck@Yahoo.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.1) Gecko/20040707
MIME-Version: 1.0
To: Jens Lechtenboerger <lechten@wi.uni-muenster.de>
Cc: Greg Stark <gsstark@mit.edu>, 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>
	<87is73qrde.fsf@stark.xeocode.com>	<m2y8fyl58u.fsf@pcwi4002.uni-muenster.de>
	<41C1CE7A.10405@Yahoo.com>	<m21xdpkpgy.fsf@pcwi4002.uni-muenster.de>
	<41C306A1.1070807@Yahoo.com>
	<m2sm64j1pa.fsf@pcwi4002.uni-muenster.de>
In-Reply-To: <m2sm64j1pa.fsf@pcwi4002.uni-muenster.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

On 12/17/2004 12:04 PM, Jens Lechtenboerger wrote:

> Jan Wieck <JanWieck@Yahoo.com> writes:
> 
>> [...]
>> The PostgreSQL team members (me included) are big fans of
>> portability. Introducing code that solves a problem for one specific web
>> server,
> 
> I don't see how this is web server specific?
> 
>> in the special case of a small number of application users,
> 
> Actually, I'm not sure that this should bother you.  As I wrote
> previously: I can put just the same load on the database server
> using Java applets right now.  In fact, the load with applets would
> even be higher, as the database server does not receive any hint
> when the connection is idle for some time...
> 
>> in a non portable way for only a couple operating systems
> 
> I get this point.
> 
>> and where the resulting functional difference is visible to the
>> database client ...
> 
> If it wasn't visible, then it would be useless for me.

I meant that there would be a functional difference between databases 
running on different operating systems. Like "if you want connection 
suspend/resume to work your DB server must run on OS foo or bar ...".

> 
>> I don't think this idea has much of a chance to make it into the
>> source tree.
> 
> I'm disappointed, though, and summarize:
> PostgreSQL transactions cannot be used naturally with CGI/PHP, and
> virtually every web application out there is prone to lost updates.

As said, open transactions with DB locks during user interaction are a 
known bad idea for every sort of application. That together with the 
scaling problems is IMHO reason enough not to implement something that 
is designed to avoid proper application side advisory locks.

Get used to put reasonable amounts of your business logic into stored 
procedures on the database side and you will find that dealing with 
advisory locks is not as painfull as it looks like. Doing it all with 
PHP coding alone, where a single business process is scattered over a 
input form flow dictated number of source files is neither as easy, nor 
as maintainable.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #