Vlad, your explanation is very good, but I still don't understand something: Why before step 1 the engine does not blocks the record avoiding such problem?
Greetings. Walter. On Sat, Dec 27, 2014 at 5:19 AM, [email protected] [firebird-support] <[email protected]> wrote: > > > Update, internally, consists of following steps (simplified) : > > 1. read record > 2. evaluate new record > 3. write new record into data page > > really, it is a more complex, but for now we interesting only in steps > above. > > At step 1, read-committed (RC) transaction waits for commit or rollback of > concurrent active transaction and thus reads only comitted record version. > > At step 3, transaction re-reads original record version and must ensure > that it is still the same record version as it was at step 1 (else we will > silently replace other's work). If current record version was changed since > step 1, update_conflict error will be reported - exactly as you see. > Again, it is simplified description. > > Note, time slice between steps 3 and 1 usually very small. When you test > concurrent updates in isql, you can't reproduce such scenario. But in real > life, when you have a lot of concurrent updates by applications it becomes > much more probably and really happens sometimes. > > Hope it helps, > Vlad > >
