3

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?

Improve this question

1 Answer 1

Reset to default
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:

  1. If the read comes first it S-locks the row and the write must wait.
  2. If the write comes first the S-lock waits for the write to commit.

Under Hekaton it works differently because there are no locks.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Right, so it does wait, then? So Transaction A doesn't actually prevent Transaction B making it's update - it just makes it wait until Transaction A has finished before doing so?
It waits before making the write or read of that specific row. Isn't the answer clear that it waits?

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.