Message-ID: <41C49F87.8070709@Yahoo.com>
Date: Sat, 18 Dec 2004 16:22:15 -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: Greg Stark <gsstark@mit.edu>
Cc: Jens Lechtenboerger <lechten@wi.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>
	<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>
	<41C31A2E.9030107@Yahoo.com> <87hdmkkd87.fsf@stark.xeocode.com>
In-Reply-To: <87hdmkkd87.fsf@stark.xeocode.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

On 12/17/2004 1:10 PM, Greg Stark wrote:

> Jan Wieck <JanWieck@Yahoo.com> writes:
> 
>> 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.
> 
> I think it's a higher level divergence of opinion here. What he's talking
> about is more like the Java/J2EE approach of building lots of infrastructure
> to make everything work magically. Our instincts are to keep things simple and
> avoid big hammers for features that would be hard to manage.

ANSI SQL doesn't specify any lock timeouts or possibility to cancel 
someone elses transaction, heck it doesn't even define any way to find 
out what particular lock is held by what session. Maybe a database 
system that is oriented towards standard conformance isn't the right 
choice for this environment.

Standard conformant SQL databases do not work well with open 
transactions holding locks during user interactions. That is a fact. I 
would object to adding proprietary features to PostgreSQL so that the 
application developer can use some sort of SQL looking gibberish instead 
of creating the appropriate framework. I am however only one developer, 
and if other key members of the developer community are in favor for it, 
I can certainly ignore such feature - given it wouldn't affect the rest 
of PostgreSQL's features or performance as long as not used.


Jan

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