RE: SELECT FOR UPDATE
От | Willis, Ian (Ento, Canberra) |
---|---|
Тема | RE: SELECT FOR UPDATE |
Дата | |
Msg-id | D21A20CD84607E409F314E31F0F68D8A654D9A@cricket-be.ento.csiro.au. обсуждение исходный текст |
Ответ на | SELECT FOR UPDATE (jose <jose@sferacarta.com>) |
Список | 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 по дате отправления: