Subject | Re: [firebird-support] Deadlock exception occurs but it shouldn't? |
---|---|
Author | |
Post date | 2014-12-27T09:19:05Z |
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
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