From: | Jens Lechtenboerger <lechten(at)wi(dot)uni-muenster(dot)de> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-interfaces(at)postgresql(dot)org |
Subject: | Re: Lost updates vs resumable connections/transactions |
Date: | 2004-12-17 18:07:08 |
Message-ID: | m2hdmk3ik3.fsf@pcwi4002.uni-muenster.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> On 12/17/2004 12:04 PM, Jens Lechtenboerger wrote:
>
>> Jan Wieck <JanWieck(at)Yahoo(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2004-12-17 18:10:16 | Re: Lost updates vs resumable connections/transactions |
Previous Message | Jan Wieck | 2004-12-17 17:41:02 | Re: Lost updates vs resumable connections/transactions |