How to use Firebird transaction isolation levels with UIB?

Question

According to documents there are four transaction isolation levels in Firebird. However, as far as I know, there's no explicit isolation level selection in uib library (TUIBTransaction), but bunch of options for transactions. How I should use those? Is there documentation somewhere?

Answer 1

These bunch of options are what will change the isolation level. As @Arioch said in his compact comment, you can change the isolation level changing the property Options that is of type TTransParams. This is a set of TTransParam as below.

 // Transaction parameters
TTransParam = (
{ prevents a transaction from accessing tables if they are written to by
other transactions.}
tpConsistency,
{ allows concurrent transactions to read and write shared data. }
tpConcurrency,
{ Concurrent, shared access of a specified table among all transactions. }
{$IFNDEF FB_21UP}
tpShared,
{ Concurrent, restricted access of a specified table. }
tpProtected,
tpExclusive,
{$ENDIF}
{ Specifies that the transaction is to wait until the conflicting resource
is released before retrying an operation [Default]. }
tpWait,
{ Specifies that the transaction is not to wait for the resource to be
released, but instead, should return an update conflict error immediately. }
tpNowait,
{ Read-only access mode that allows a transaction only to select data from tables. }
tpRead,
{ Read-write access mode of that allows a transaction to select, insert,
update, and delete table data [Default]. }
tpWrite,
{ Read-only access of a specified table. Use in conjunction with tpShared,
tpProtected, and tpExclusive to establish the lock option. }
tpLockRead,
{ Read-write access of a specified table. Use in conjunction with tpShared,
tpProtected, and tpExclusive to establish the lock option [Default]. }
tpLockWrite,
tpVerbTime,
tpCommitTime,
tpIgnoreLimbo,
{ Unlike a concurrency transaction, a read committed transaction sees changes
made and committed by transactions that were active after this transaction started. }
tpReadCommitted,
tpAutoCommit,
{ Enables an tpReadCommitted transaction to read only the latest committed
version of a record. }
tpRecVersion,
tpNoRecVersion,
tpRestartRequests,
tpNoAutoUndo
{$IFDEF FB20_UP}
,tpLockTimeout
{$ENDIF}
); 

Since Interbase 6.0 code "opensourced", the documentation for the API hasn't changed much. So if you want an explanation about any of them the docs you are looking are in Interbase manuals.

You can get them here https://www.firebirdsql.org/en/reference-manuals/

Below I'm quoting Ann Harrison in this link to an quick explanation on the usual options used:

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.

NOTE: I hope that you can see that, beside the parameters are not named equally, it's not that hard to understand if you remove the "isc_tpb_" part.