On Sat, Dec 27, 2014 at 5:19 AM, hvlad@... [firebird-support] <firebird-support@yahoogroups.com> 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