Scribd
Upload
6 views3 pages

Seminar 6 - Subject I

The document describes an interleaved execution scenario in SQL Server involving a Customer table with various transaction isolation levels. It outlines the operations performed by two transactions (T1 and T2) that attempt to update the same record simultaneously, leading to locking conflicts. The document also explains the types of locks used in SQL transactions and their behavior under different isolation levels.

Uploaded by

Rares Oana
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
6 views3 pages

Seminar 6 - Subject I

The document describes an interleaved execution scenario in SQL Server involving a Customer table with various transaction isolation levels. It outlines the operations performed by two transactions (T1 and T2) that attempt to update the same record simultaneously, leading to locking conflicts. The document also explains the types of locks used in SQL transactions and their behavior under different isolation levels.

Uploaded by

Rares Oana
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

I.

Consider relation Customer[CustomerID, FirstName, LastName, City, DateOfBirth] and the


following interleaved execution in SQL Server:
create database DBMS_Sem6_online
go
use DBMS_Sem6_online
go

create table Customer(


CustomerID int primary key identity,
FirstName varchar(50),
LastName varchar(50),
City varchar(50),
DateofBirth date
)

insert into Customer values ('Ana', 'Maria', 'Alba-Iulia', '2000-04-04'), ('Popescu',


'Iulian', 'Timisoara', '1999-05-05')

select * from Customer

-- after each execution


update Customer set City='Timisoara' where CustomerID=2

T1 T2
use DBMS_Sem6_online use DBMS_Sem6_online
go go

-- first version - as it is -- first version - as it is


-- second version -- second version
-- set transaction isolation level READ UNCOMMITTED -- set transaction isolation level READ UNCOMMITTED
-- third version -- third version
-- set transaction isolation level READ COMMITTED -- set transaction isolation level REPEATABLE READ
-- forth version -- forth version
-- set transaction isolation level REPEATABLE READ -- set transaction isolation level READ COMMITTED
BEGIN TRAN BEGIN TRAN
select City from Customer where CustomerID=2 update Customer set City='Cluj-Napoca' where
waitfor delay '00:00:10' CustomerID=2
update Customer set City='Bucuresti' where waitfor delay '00:00:10'
CustomerID=2 ROLLBACK TRAN
COMMIT TRAN

1
1. c
2. c
3. b, c, d

In this interleaved execution in SQL Server, the order of the operations is:
* the initial value for the record with CustomerID=2 from the table Customer is, for the field
City = Timisoara

- T1, executes the select from the Customer table, getting the shared lock on this table
- The next operation is the update from T2, that is also getting an exclusive lock (we also know,
that, exclusive locks protect updates to file resources and can be owned by only one transaction
at a time). In this transaction, T2, the table Customer is updated for the record with the
CustomerID=2 (the new value for the City becomes Cluj-Napoca).

2
- The next operation is the update from T1, that also needs an exclusive lock. In this transaction,
T1, the table Customer is updated for the record with the CustomerID=2 (the new value for the
City becomes Bucuresti).
So, for the update operation, both transactions need the exclusive lock.

READ LOCK = SHARED LOCK (S) = SELECT statement

WRITE LOCK = EXCUSIVE LOCK (X) = UPDATE statement / INSERT statement / DELETE
statement

From Seminar 3:

• READ UNCOMMITTED: no S locks when reading data


• READ COMMITTED: S locks - released as soon as the SELECT operation is performed;
X locks - released at the end of the transaction
• REPEATABLE READ: holds S locks and X locks until the end of the transaction
• SERIALIZABLE: holds locks (including key-range locks) during the entire transaction

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy