From: | "Willis, Ian (Ento, Canberra)" <Ian(dot)Willis(at)ento(dot)csiro(dot)au> |
---|---|
To: | Postgres <pgsql-general(at)postgresql(dot)org> |
Subject: | RE: SELECT FOR UPDATE |
Date: | 2001-08-24 03:56:42 |
Message-ID: | D21A20CD84607E409F314E31F0F68D8A654D9A@cricket-be.ento.csiro.au. |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
You should handle this at the application level as well.
User 1 and 2 open and Work on page
User 1 commits changes
User 2 goes to commits change and gets error message pages updated during
editing.
User 2 could be Prompted overwrite current values, user1's
update would be lost.
Save page under a different value
Merge data ...
--
Ian Willis
-----Original Message-----
From: Oliver Elphick [mailto:olly(at)lfix(dot)co(dot)uk]
Sent: Friday, 24 August 2001 2:06 AM
To: Mike Castle
Cc: Postgres
Subject: Re: [GENERAL] SELECT FOR UPDATE
Mike Castle wrote:
>On Thu, Aug 23, 2001 at 10:09:19AM -0400, Jan Wieck wrote:
>> Oliver Elphick wrote:
>> > I can see arguments to support this view, but consider this classic
>> > scenario:
>> >
>> > User1: Read data into an interactive program
>> > User1: Start to make changes
>> > User2: Read data into an interactive program
>> > User2: Start to make changes
>> > User1: Save changes
>> > User2: Save changes
>
>Consider replacing "Save changes" with:
>
>User1: Lock record, compare original with current record, save if same,
unlo
>ck
>User2: Lock record, compare original with current record, notice
difference,
> abort.
Yes, but if User2 has done substantial editing changes to a field (after all
we could store whole books in a SQL field now), his changes will be rejected
and the program will have to throw them away or else try to integrate them
with the new field contents - in either case there is substantial wasted
effort.
I prefer Jan's solution: on first attempt to change, acquire a user-level
lock by creating a lock record; if you can't get the lock, don't allow
any change.
However, it would be convenient if the database would do this for me. I
still don't understand why people think it undesirable for it to do so,
since
it is a problem universal to multi-user databases and the effort is
therefore more economically spent at the database rather than at the
application level.
--
Oliver Elphick Oliver(dot)Elphick(at)lfix(dot)co(dot)uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"For God hath not appointed us to wrath, but to obtain
salvation by our Lord Jesus Christ, Who died for us,
that, whether we wake or sleep, we should live
together with him."
I Thessalonians 5:9,10
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
From | Date | Subject | |
---|---|---|---|
Next Message | Tsukaeru.net Webmaster | 2001-08-24 03:58:01 | Re: Backend message type 0x44 arrived while idle |
Previous Message | Tom Lane | 2001-08-24 03:31:14 | Re: Backend message type 0x44 arrived while idle |