Issue Details (XML | Word | Printable)

Key: DNET-337
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Jiri Cincura
Reporter: kdv
Votes: 2
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
.NET Data provider

Wrong tpb parameters for standard transaction isolation modes

Created: 02/Aug/10 08:42 AM   Updated: 27/Oct/12 07:15 PM
Component/s: ADO.NET Provider
Affects Version/s: None
Fix Version/s: 3.0.0.0

Issue Links:
Relate
 


 Description  « Hide
Currently page
http://www.firebirdsql.org/dotnetfirebird/transaction-isolation-levels.html
and implementation of IsolationLevel.ReadUncommitted and IsolationLevel.ReadCommitted is not correct.

IsolationLevel.ReadUncommitted have READ COMMITTED RECORD_VERSION tpb options, wich is wrong, because in the Firebird ReadUncommitted can be simulated only like this:
read committed no record version no wait

This will cause an error if transaction will attempt to read records with uncommitted versions. Even with this options it will be semi-ReadUncommitted, because Firebird will not allow to read uncommitted data in any way.

Otherwise, IsolationLevel.ReadCommitted uses mentioned above "no record version" option, which does not allow to read only committed versions (error on nowait and lock on wait).
Instead, ReadCommitted must use
read committed record version no wait

This tpb parameters exactly corresponds to the standard ReadCommitted isolation mode.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
kdv added a comment - 02/Aug/10 09:03 AM
as I understand, JayBird and ODBC drivers have the same problem, and the source of the problem is that by default tpb option of read committed is no_rec_version.
Yes, it is default for Firebird's and (Interbase-s) tpb options, but this is wrong for the ReadCommitted isolation mode. TPB options for ReadCommitted must not lock (wait) or return error (no wait) when reading records with uncommitted versions (which no_rec_verison option does).

I hope that I've explained the problem. It was also in BDE (fixed in BDE 4.1 and higher) and maybe exists in some other drivers (except IBX and FIBPlus components). Maybe the cause is a bit unclear name of the no_rec_version option.

IB Api Gude (v6.0), page 424:

isc_tpb_rec_version
Enables an isc_tpb_read_committed transaction to read the most recently
committed version of a record even if other, uncommitted versions are
pending.

isc_tpb_no_rec_version
Enables an isc_tpb_read_committed transaction to read only the latest
committed version of a record
If an uncommitted version of a record is pending and isc_tpb_wait is also
specified, then the transaction waits for the pending record to be committed
or rolled back before proceeding; otherwise, a lock conflict error is reported at
once