From: Jan Wieck <JanWieck@Yahoo.com>
To: Greg Stark <gsstark@mit.edu>
Cc: Jens Lechtenboerger <lechten@wi.uni-muenster.de>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Lost updates vs resumable connections/transactions
Date: Sat, 18 Dec 2004 16:22:15 -0500
Message-ID: <41C49F87.8070709@Yahoo.com> (raw)
In-Reply-To: <87hdmkkd87.fsf@stark.xeocode.com>
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>
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 #
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: JanWieck@Yahoo.com, gsstark@mit.edu, lechten@wi.uni-muenster.de
Subject: Re: Lost updates vs resumable connections/transactions
In-Reply-To: <41C49F87.8070709@Yahoo.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox