Update statements with set transaction isolation level read uncommitted
If I have a stored procedure with set transaction isolation level read uncommitted, will it affect update statements?
Read uncommitted allows dirty reads. An X
lock will be taken on the row or higher level (in the data page or index) before it is made dirty. Rows accessed directly by the query when locating a row to update will take a U
lock and be blocked.
However it is still possible for an Update to be affected by the isolation level.
Connection 1
CREATE TABLE T1
(
X INT NULL,
Y INT NULL
);
INSERT INTO T1 DEFAULT VALUES;
BEGIN TRAN
UPDATE T1 SET X = 100;
WAITFOR DELAY '00:00:10'
ROLLBACK;
Connection 2 (run this within 10 seconds of firing off connection 1)
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
UPDATE T1
SET Y = (SELECT SUM(X)
FROM T1);
SELECT *
FROM T1;
Result
The read operation read the uncommitted value and the final result was used in the UPDATE
even though the 100
that was read was eventually rolled back.
"Transaction isolation level" mainly affects (in my understanding) the behavior of the read operation, i.e. whether a read operation will issue some locks. In the case of "read uncommitted", here is a quote from MSDN
Transactions running at the READ UNCOMMITTED level do not issue shared locks to prevent other transactions from modifying data read by the current transaction. READ UNCOMMITTED transactions are also not blocked by exclusive locks that would prevent the current transaction from reading rows that have been modified but not committed by other transactions
So to your question, the answer is NO, the update will not be affected by "read uncommitted" transaction isolation level inside the same stored procedure.
-- Update (a sample to prove this logic) In SSMS, we open two windows, and in Window 1 (W1 hereafter), run the following
use tempdb
create table dbo.t (a int)
go
insert into dbo.t (a) values (10)
go
begin tran
update dbo.t
set a = 20
where a = 10
-- commit tran
In another Window (W2), run the following (see the comments for the behavior)
use TempdB
set transaction isolation level read uncommitted
select * from dbo.t -- you can have dirty read, showing [a]=20, which is an uncommitted UPDATE in W1
go
-- the following update will wait (before proper locks are granted)
update dbo.t
set a = 30
where a= 10
This means the UPDATE statement in W2 (with READ UNCOMMITTED) is not impacted by the transaction isolation level (i.e. still behaves as expected) as the SELECT statement.
-- UPDATE 2: According to MSDN UPDATE t-sql,
WITH ( Table_Hint_Limited )
Specifies one or more table hints that are allowed for a target table. The WITH keyword and the parentheses are required. NOLOCK and READUNCOMMITTED are not allowed. For information about table hints, see Table Hints (Transact-SQL).
So my understanding is that when you run UPDATE statement, in SQL Server, there is no way that you can update on dirty data (i.e. uncommitted data) even if you can read the dirty data in your session.
Based on your edit, now the question is more clear ..
so my question is whether putting "set transaction ..." at the top of my stored proc is ever going to be honored by update/delete statements or whether it will be ignored.
Transaction isolation level should be thought in terms of read operations. Isolation levels control how the read operations are protected from the other write operations.
The database engine governs the locking behavior of all write operations, and you cannot change that behavior at the database level.
From BOL :
All isolation levels always issue exclusive locks for write operations and hold the locks for the entire duration of the transaction.
Read up :
- How do I set the default transaction isolation level for write operations?
- Transaction Isolation Levels
- Are all updates split into delete-insert?