If user B waits, he will wait at the UPDATE statement (because of the implicit lock), in that case he has already passed the checksum check. So he will not get an error, he will overwrite the changes of user A.Scenario 1:
User B will wait until User A's transaction completes. [...] User B will receive an error stating that the data has changed.
I think I have a compromise. When you implement the WAIT with 1, 2 or x seconds we can have the old behavior that the second users waits. In the case nothing is changed by user A, the transaction of user B go's through.Scenario 2:
Well, the problem is that it seems not always the case. According to Patrick first scenario, which was confirmed by Joel ("Very good point - and you are correct. That is how Scenario 1 would occur.") my situation can yield two tickets for the same seat, and not an error message."In your case if user B will try to post (at the end of page) the record (free seats) .. he will face Error page with ORA message which will tell him that this record (free seat) doesn't exist anymore."
I'm talking about a very simple case – only two users, one table and updates using APEX automatic DML. It seems that in a specific situation - which is out of my control, it is all about timing - I can face a problem of lost update, although using only built-in APEX resources. That's constitute a problem from me." If I may tell in simple relations (few involving tables) with not too much concurrent users...probably automatic DML is OK."
for i in 1...[checked fields] loopIn this way, some of the reservations will be placed and in a case of some problems. It is more then easy to show on next page result of update. If you need all or nothing process then do not use autonomous transactions but code like this:
when others then
remember records that are not updated;
regular_exit := true;Hope this helps....
for i in 1...[checked fields] loop
when others then
Rollback; -- explicit
if regular_exit then