From: Jan Wieck <JanWieck@Yahoo.com>
To: Jens Lechtenboerger <lechten@wi.uni-muenster.de>
Cc: Greg Stark <gsstark@mit.edu>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Lost updates vs resumable connections/transactions
Date: Fri, 17 Dec 2004 12:41:02 -0500
Message-ID: <41C31A2E.9030107@Yahoo.com> (raw)
In-Reply-To: <m2sm64j1pa.fsf@pcwi4002.uni-muenster.de>
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>
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 #
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, lechten@wi.uni-muenster.de, gsstark@mit.edu
Subject: Re: Lost updates vs resumable connections/transactions
In-Reply-To: <41C31A2E.9030107@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