Re: Lost updates vs resumable connections/transactions

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Jens Lechtenboerger <lechten(at)wi(dot)uni-muenster(dot)de>
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 17:41:02
Message-ID: 41C31A2E.9030107@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

On 12/17/2004 12:04 PM, Jens Lechtenboerger wrote:

> Jan Wieck <JanWieck(at)Yahoo(dot)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(at)Yahoo(dot)com #

In response to

Responses

Browse pgsql-interfaces by date

  From Date Subject
Next Message Jens Lechtenboerger 2004-12-17 18:07:08 Re: Lost updates vs resumable connections/transactions
Previous Message Jens Lechtenboerger 2004-12-17 17:04:33 Re: Lost updates vs resumable connections/transactions