> 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 ?