I think I dont understand for what I can use than "select for update"
when not for the following scenario??--> For example when I have a table
A with row a1 and user u1 will update
a1 so he select a1 for update... and this without a commit till the user
change values of a1 and commit this with a GUI button.. so when an
other user u2 will also update a2 then I expect that a SQLException is
throw like :"an other user is selected this row for update" OR he get
the exception when u2 want commit a "select for update" before a1 do
this...
hmm..
>
>
>
>I can't see why you couldn't insert the user in a first transaction and
>the addresses in further transactions... if the user gets deleted in the
>meantime by somebody else, then inserting the address will fail and you
>will tell the user about the error. And if you don't want other people
>to see the new user before it is committed with all it's addresses, then
>collect first the user data + all the address data, and then open a
>transaction and insert the user and the addresses when the user presses
>OK. The point is that there should not be any GUI activity between the
>start and end of a transaction.
>If you really need a lock (I doubt it) between updates, implement it
>using some application logic, don't use the DB row locking for long
>living locks. I think there is some locking helper in the contrib
>modules of postgres, or if not, read up on resource locking on google.
>
>Cheers,
>Csaba.
>
>
>
>
>
