Database Reference
In-Depth Information
It is important to note that the transaction maintains a
write set
, or pointers to rows that have been inserted and
deleted by a transaction. Moreover, in
SERIALIZABLE
and
REPEATABLE READ
isolation levels, transactions maintain a
read set
of the rows that were read by a transaction. The write set is used to generate transaction log records (more on
this later), while the read set is used to perform
REPEATABLE READ
and
SERIALIZABLE
rules validation.
When a
COMMIT
request is issued, the transaction starts the validation phase. First it generates a new
Global
Transaction Timestamp
value and replaces the
TransactionId
with this value in all
BeginTs
and
EndTs
timestamps in
the rows it modified. Figure
32-20
illustrates this action, assuming that the
Global Transaction Timestamp
value is 11.
Figure 32-20.
Validation phase after BeginTs and EndTs values are replaced
At this moment, the rows modified by transaction become visible to other transactions in the system even
though the transaction has yet to be committed. Other transactions can see uncommitted rows, which leads to a
situation called
commit dependency
. These transactions would not be blocked at the time when they access those
rows, however, they would not return data to clients nor commit until the original transaction on which they have
a commit dependency would commit itself. If, for some reason, that transaction failed to commit, other dependent
transactions would be rolled back and an error would be generated.
Commit dependency is technically a case of blocking in in-memory OLTP. However, the validation and commit
phases of transactions are relatively short, and that blocking should not be excessive.
After the timestamps in the rows are replaced, the transaction validates the
REPEATABLE READ
and
SERIALIZABLE
rules and waits for the commit dependencies to clear. When it is done, the transaction moves to the commit phase,
generates one or more log records, saves them to the transaction log, and completes the transaction.
It is worth noting that the validation phase of the transaction in
REPEATABLE READ
and
SERIALIZABLE
isolation
levels is longer than in
SNAPSHOT
transactions due to rules validation.
■
Do not use
REPEATABLE READ
and
SERIALIZABLE
isolation levels unless you have a legitimate use-case
for such data consistency.
Important
■
you can read more about the concurrency model in in-memory OLtP at:
Note
