> The problem is that the read_committed transaction will fail if it > tries to update a record version created by a concurrent transaction, > even if that transaction has committed. It's kinda dumb, but that's > the way it's implemented. Read-committed transactions follow the same > update concurrency rules as consistent read transaction. Even though a > read-committed transaction can read a record version that was created > and committed by a concurrent transaction, it can can't update that > version.
hello ann, i just make some try (reading one of your article where you write beleave the code, not the comments) and this is my test 2 threads isc_tpb_write isc_tpb_read_committed isc_tpb_no_rec_version isc_tpb_wait 1rt thread Start a massive update that take 10 min to finish (update tableA set fieldA = 'xxx'); that let me the time to start thread2 So i launch a second thread that do some insert/delete/update in last reccord in the tableA (that are not yet processed by the massive update) If i not commit the modification in the 2nd thread, then when the 1rt thread will arrive on the reccord updated/inserted/deleted by the 2nd thread it's will wait a commit/roolback. if in the 2nd thread i commit, then First thread will finish peacefully without any error so i no understand how it's possible to have any deadlock ?
