pg.ddx.io  pgsql-interfaces@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Jens Lechtenboerger <lechten@wi.uni-muenster.de>
To: Jan Wieck <JanWieck@Yahoo.com>
Cc: Greg Stark <gsstark@mit.edu>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Lost updates vs resumable connections/transactions
Date: Fri, 17 Dec 2004 19:07:08 +0100
Message-ID: <m2hdmk3ik3.fsf@pcwi4002.uni-muenster.de> (raw)
In-Reply-To: <41C31A2E.9030107@Yahoo.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>

Jan Wieck <JanWieck@Yahoo.com> writes:

> On 12/17/2004 12:04 PM, Jens Lechtenboerger wrote:
>
>> Jan Wieck <JanWieck@Yahoo.com> writes:
>>
>>> [...]
>>> 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.

After writing my last mail, I was riding my bicycle through the rain
and thought about the following additional application areas for an
API extension:

Grid computing: I might want to transfer a transaction from an
overloaded client node to another node.  Currently, this is not
possible.

Web services: I might want to compose an atomic service out of
component services over a single database.  In contrast to my
previous web example, in this scenario there needn't be user
interaction between the individual service invocations.

> 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.

There is a fundamental problem.  It's not about "scattered" business
processes but about the very simple "look and edit" process that is
not supported.

Jens




view thread (15+ messages)  latest in thread

Message-ID: <m2hdmk3ik3.fsf@pcwi4002.uni-muenster.de>
Permalink:  ../m2hdmk3ik3.fsf@pcwi4002.uni-muenster.de/
Also on:    postgresql.org/message-id/m2hdmk3ik3.fsf@pcwi4002.uni-muenster.de

 · 

reply

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: lechten@wi.uni-muenster.de, JanWieck@Yahoo.com, gsstark@mit.edu
  Subject: Re: Lost updates vs resumable connections/transactions
  In-Reply-To: <m2hdmk3ik3.fsf@pcwi4002.uni-muenster.de>

* 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