Thanks Ann ! by the way i use isc_tpb_read_committed + isc_tpb_no_rec_version + isc_tpb_wait but i have all the time deadlock when i do massive update (update on thousands rows)
What can cause a deadlock when using isc_tpb_read_committed + isc_tpb_no_rec_version + isc_tpb_wait ? because i was thinging that the transaction simply wait (undefinitively?) that rec are committed instead of raising a deadlock ... thanks ! --- In [email protected], Ann Harrison <aharrison@...> wrote: > > On Mon, Feb 27, 2012 at 3:38 AM, nathanelrick <nathanelrick@...> wrote: > > > > what is the most fastest isolation level ? > > i know the behavior of each, but i need to know the difference in speed / > > resource usage between each of them ... > > > > isc_tpb_concurrency > > isc_tpb_consistency > > isc_tpb_read_committed + isc_tpb_rec_version > > isc_tpb_read_committed + isc_tpb_no_rec_version > > > > isc_tpb_consistency can cause performance problems due the fact that > it's locking tables and possibly excluding concurrent access. > > isc_tpb_concurrency is the design center for Firebird. Readers don't > block writers, writers don't block readers, and both get a consistent > view of the database. > > isc_tpb_read_committed + isc_tpb_rec_version + isc_tbp_read_only give > inconsistent results and occasionally produces an error on a blob > read*, but unlike other modes, it does not block garbage collection so > it's a good mode for long running read transactions that don't have to > get the "right" answer. > > isc_tpb_read_committeed + isc_tpb_rec_version has the same performance > as isc_tpb_concurrency, but gets inconsistent results - the same query > run twice in the same transaction may return different rows. > > isc_tpb_read_committed + isc_tpb_no_rec_version + isc_tpb_wait is > slower than other modes because it will wait for a change to be > commited rather than reading the newest committed version. Like all > variants of isc_tpb_read_committed, it does not produce consistent > results. > > isc_tpb_read_committed + isc_tpb_no_rec_version + isc_tpb_no_wait > gives lots and lots of deadlock errors because every time a reader > encounters a record that's being changed, it returns an error. > > > Good luck, > > Ann > > > * If you have the bad luck to read a record version which includes a > blob and someone else changes the record version and the blob, and > that transaction commits, and somebody else comes by and garbage > collects the record version and blob before you get around to reading > the blob, you'll get an error. Doesn't happen in other modes. >
