问题
I feel like I should know this, but I can't find anything that specifically outlines this, so here goes.
The documentation for SQL Server describes REPEATABLE READ as:
Specifies that statements cannot read data that has been modified but not yet committed by other transactions and that no other transactions can modify data that has been read by the current transaction until the current transaction completes
This makes sense, but what actually happens when one of these situation arises? If, for example, Transaction A reads row 1, and then Transaction B attempts to update row 1, what happens? Does Transaction B wait until Transaction A has finished and then try again? Or is an exception thrown?
回答1:
REPEATABLE READ takes S-locks on all rows that have been read by query plan operators for the duration of the transaction. The answer to your question follows from that:
- If the read comes first it S-locks the row and the write must wait.
- If the write comes first the S-lock waits for the write to commit.
Under Hekaton it works differently because there are no locks.
来源：https://stackoverflow.com/questions/30238059/sql-server-2012-how-does-repeatable-read-isolation-level-work