What does Rollback mean in a concurrent environment?

Question

This question is about T-SQL/SQL Server.

Suppose we have a transaction that inserts some row X1 into table X, updates row X2 in table X, and then issues a rollback.

Right before the rollback, a second transaction updates rows X1 and X2 in table X and commits. (I suppose that in order to update X1, that transaction must have isolation level Read Uncommitted.)

What is the state of rows X1 and X2 after the first transaction's rollback?

Answer 1

You can't update X1 and X2 in the second transaction. Any write operation takes exclusive (X) locks regardless of the specified transaction level. This is exactly to prevent the scenario in your question and to guarantee the ACID properties of each transaction.

If you specify "read uncommitted" the only thing you can do is read the changed values from the first transaction. You see the new record X1 and the modified record X2, because "read uncommitted" takes no read locks and thus ignores the X-Locks placed in the first transaction. However, modifying these values still would require X-Locks of your own, which you won't get until transaction 1 finishes.

Edit: If you want to explore locking behaviour in SQL Server, I encourage you to open a profiler session, select the "TSQL_Locks" template, add the "Lock: Acquired" and "Lock: Released" events and filter the events based on you SPID (the bracketed number in your Management Studio session tab, usually something like 51 or greater).

Then fire off some read and write statements on a simple table with different isolation levels and see what happens. Important columns are "EventClass", "Mode", "ObjectId", "TextData" and "Type". If yiu send a statement for the first time you get loads of schema locks associated with compiling the statement. Just issue the same statement a second time to get a clearer view on the important locks.