From the support list, by Ann Harrison, as a reminder :

  • 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 blockwriters, writers don't block readers, and both get a consistent view of thedatabase.
  • iisc_tpb_read_committed + isc_tpb_rec_version + isc_tbp_read_only giveinconsistent 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 asisc_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 slowerthan other modes because it will wait for a change to be commited rather than reading the newest committed version. Like all variants ofisc_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.