RE: SELECT FOR UPDATE - Mailing list pgsql-general

From Willis, Ian (Ento, Canberra)
Subject RE: SELECT FOR UPDATE
Date
Msg-id D21A20CD84607E409F314E31F0F68D8A654D9A@cricket-be.ento.csiro.au.
Whole thread Raw
In response to SELECT FOR UPDATE  (jose <jose@sferacarta.com>)
List 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@lfix.co.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.Elphick@lfix.co.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

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Backend message type 0x44 arrived while idle
Next
From: "Tsukaeru.net Webmaster"
Date:
Subject: Re: Backend message type 0x44 arrived while idle