The following
LIBNAME and data set options let you control how the ODBC interface
handles locking. For general information about an option, see
LIBNAME Options for Relational Databases.
READ_LOCK_TYPE= ROW | TABLE | NOLOCK
UPDATE_LOCK_TYPE= ROW | TABLE | NOLOCK
READ_ISOLATION_LEVEL= S | RR | RC | RU | V
The ODBC driver manager
supports the S, RR, RC, RU, and V isolation levels that are defined
in this table.
Isolation Levels for ODBC
|
|
|
Does not allow dirty
Reads, nonrepeatable Reads, or phantom Reads.
|
|
Does not allow dirty
Reads or nonrepeatable Reads; does allow phantom Reads.
|
|
Does not allow dirty
Reads or nonrepeatable Reads; does allow phantom Reads.
|
|
Allows dirty Reads,
nonrepeatable Reads, and phantom Reads.
|
|
Does not allow dirty
Reads, nonrepeatable Reads, or phantom Reads. These transactions
are serializable but higher concurrency is possible than with the
serializable isolation level. Typically, a nonlocking protocol is
used.
|
Here are how the terms
in the table are defined.
A transaction that
exhibits this phenomenon has very minimal isolation from concurrent
transactions. In fact, it can see changes that are made by those concurrent
transactions even before they commit.
For example, suppose
that transaction T1 performs an update on a row, transaction T2 then
retrieves that row, and transaction T1 then terminates with rollback.
Transaction T2 has then seen a row that no longer exists.
If a transaction exhibits
this phenomenon, it is possible that it might read a row once and
if it attempts to read that row again later in the course of the same
transaction, the row might have been changed or even deleted by another
concurrent transaction. Therefore, the read is not (necessarily) repeatable.
For example, suppose
that transaction T1 retrieves a row, transaction T2 then updates that
row, and transaction T1 then retrieves the same row again. Transaction
T1 has now retrieved the same row twice but has seen two different
values for it.
When a transaction
exhibits this phenomenon, a set of rows that it reads once might be
a different set of rows if the transaction attempts to read them again.
For example, suppose
that transaction T1 retrieves the set of all rows that satisfy some
condition. Suppose that transaction T2 then inserts a new row that
satisfies that same condition. If transaction T1 now repeats its retrieval
request, it sees a row that did not previously exist, a phantom.
UPDATE_ISOLATION_LEVEL= S | RR | RC | V
The ODBC driver manager
supports the S, RR, RC, and V isolation levels defined in the preceding
table.