|Subject||Re: [firebird-support] Deadlock exception occurs but it shouldn't?|
|Author||Walter R. Ojeda Valiente|
On Sat, Dec 27, 2014 at 5:19 AM, hvlad@... [firebird-support] <email@example.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,