> 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.
Thanks for this very good explanation > > I stand by my preference for concurrency as an isolation mode. > but it's seam that the probleme is even worse with concurency than with isc_tpb_read_committed i just do this try : isc_tpb_read_committed isc_tpb_no_rec_version isc_tpb_wait client 1 update rec 'xxx' set label ='xxx' client 2 update rec 'xxx' set label ='www' => but the app freeze waiting client 1 commit client 1 commit => OK client 2 => OK => commit => OK now with isc_tpb_write isc_tpb_concurrency client 1 update rec 'xxx' set label ='xxx' client 2 update rec 'xxx' set label ='www' => but the app freeze waiting client 1 commit client 1 commit => OK client 2 => DEADLOCK ERROR ! so how i can do to do my massive update ? the isc_tpb_read_committed + isc_tpb_no_rec_version + isc_tpb_wait was the perfect solution (simply wait that transaction commit and update the last commited items) but now as you say it's not really the case i m lost :( does it's mean it's not possible to do any massive update on multi user table with firebird ?
