Concurrency and Transaction Processing

Concurrency models

1. Pessimistic– avoids conflicts by acquiring locks on data

that is being read, so no other processes can modify that data

– acquires locks on data being modified, so no other processes can access that data for either reading or modifying

– readers block writers and writers block readers

Concurrency models

2. Optimistic– use row versioning to allow data readers to

see the state of the data before the modification occurs

– process that modifies the data is unaffected by processes reading the data because the reader is accessing a saved version of the data rows

– readers do not block writers and writers do not block readers

Transaction Processing

• Guarantees the consistency and recoverability of databases.

• Ensures that all transactions are performed as a single unit of work even in the presence of a hardware or general system failure.

• Such transactions are referred to as having the ACID properties

ACID Properties - 1

1. AtomicityEach transaction is treated as all or nothing - it either commits or aborts

If a transaction commits, all its effects remain. If it aborts, all its effects are undone.

ACID Properties - 2

2. ConsistencyA transaction won't allow the system to arrive at an incorrect logical state. The data must always be logically correct.

ACID Properties - 3

3. IsolationSeparates concurrent transactions from the updates of other incomplete transactions

Accomplished automatically using locking or row versions

ACID Properties - 4

4. Durability

Ensures that the effects of the transaction persist even if a system failure occurs

Accomplished using write-ahead logging and automatic rollback and roll-forward of transactions during the recovery phase

Dependency/Consistency problems

1. Lost updates

Two processes read the same data and both manipulate the data, changing its value, and then both try to update the original data to the new value

Dependency/Consistency problems

2. Dirty reads

Process reads uncommitted data

Process has changed data but not yet committed the change, another process reading the data will read it in an inconsistent state

Dependency/Consistency problems

3. Non-repeatable reads (inconsistent analysis)

A process might get different values when reading the same resource in two separate reads within the same transaction

Can happen when another process changes the data in between the reads that the first process is doing

Dependency/Consistency problems

4. Phantom readsWhen membership in a set changes (a query with a predicate such as WHERE col1 < 100 is involved)Two SELECT operations using the same predicate in the same transaction return a different number of rows

Isolation Levels

1. Uncommitted Read (ANSI/ISO SQL-92)

All the problems described previously except lost updates are possible implemented by allowing your read operations to not take any locks

Isolation Levels

2. Read Committed (ANSI/ISO SQL-92)

The default isolation level

Can be either optimistic or pessimistic de-pending on the READ_COMMITTED_SNAPSHOT

database setting (ON/OFF)

Isolation Levels

3. Repeatable Read (ANSI/ISO SQL-92)

Ensuring that if a transaction revisits data that is already read, the data will not have changed. (Phantoms are possible!)

All the shared locks in a transaction must be held until the completion

Attention

• Exclusive locks must always be held until the end of a transaction, no matter what the isolation level or concurrency model

• Thus a transaction can be rolled back if necessary.

• Otherwise might be impossible to undo the work because other concurrent transactions might have changed the data

Isolation Levels

5. Snapshot (non ANSI/ISO SQL-92)

Allows processes to read older versions of committed data if the current version is locked. Not in the standard but useful!

Google for: A Critique of ANSI SQL Isolation Levels

Interesting too: The Third Manifesto, by C.J. Date and H. Darwen (or why SQL sucks)

Isolation Levels

5. Serializable

Ensuring that if a query is reissued, rows will not have been added in the interim (phantoms will not appear).

All the shared locks in a transaction must be held until completion of the transaction

Not only lock data that has been read, but also lock data that does not exist !!!

HOW READ UNCOMMITTED ALLOWS DIRTY READ

<STIL> READ COMMITTED <STIL> READ UNCOMMITTED

BEGIN TRAN BEGIN TRAN

SELECT Quantity FROM Production.ProductInventory WHERE ProductID = 872;-- returns 324

UPDATE Production.ProductInventory SET Quantity=Quantity + 200 WHERE ProductID = 872; -- Quantity is now 524 (uncommitted!!!)

SELECT Quantity FROM Production.ProductInventory WHERE ProductID = 872;-- returns 524 (the uncommitted data!)

ROLLBACK

At this point, the SELECT if executed again will return 342 !!!

READ COMMITTED without READ_COMMITTED_SNAPSHOT(HOW READ COMMITTED DOES NOT ALLOW DIRTY READS)

<STIL> READ COMMITTED <STIL> READ COMMITTED

BEGIN TRAN BEGIN TRAN

SELECT Quantity FROM Production.ProductInventory WHERE ProductID = 872;-- returns 324

UPDATE Production.ProductInventory SET Quantity=Quantity + 200 WHERE ProductID = 872; -- Quantity is now 524 (uncommitted!)

SELECT Quantity FROM Production.ProductInventory WHERE ProductID = 872;-- Blocks; writers block readers!

COMMIT TRAN

SELECT returns 524

RESULT

• NO DIRTY READS– GOOD!

• WRITERS BLOCK READERS– COULD BE BAD! LOWER CONCURRENCY!

• ANOTHER SOLUTION– USE READ_COMMITTED_SNAPSHOT

How to enable READ_COMMITTED_SNAPSHOT

EXECUTE:

ALTER DATABASE <DATABASE_NAME>SET READ_COMMITTED_SNAPSHOT ON

Enables the so called:MULTI-VERSION CONCURRENCY CONTROL(row versions are stored in the tempdb database)

READ COMMITTED with READ_COMMITTED_SNAPSHOT<STIL> READ COMMITTED <STIL> READ COMMITTED

BEGIN TRAN BEGIN TRAN

SELECT Quantity FROM Production.ProductInventory WHERE ProductID = 872;-- returns 324

UPDATE Production.ProductInventory SET Quantity=Quantity + 200 WHERE ProductID = 872; -- Quantity is now 524 (uncommitted!)

SELECT Quantity FROM Production.ProductInventory WHERE ProductID = 872;-- returns 324 (the older version)

COMMIT TRAN

Attention! At this point, the last SELECT if executed will return 524. THIS IS A NON-REPEATABLE READ!

RESULT• NO DIRTY READS

– GOOD!

• WRITERS DON’T BLOCK READERS– GOOD!

• TRADEOFF– ROW VERSIONS SHOULD BE MANAGED

• NON-REPEATABLE READ HAPPENS– COULD BE A PROBLEM

SAME with REPEATABLE READ

<STIL> READ COMMITTED <STIL> REPEATABLE READ

BEGIN TRAN BEGIN TRAN

SELECT Quantity FROM Production.ProductInventory WHERE ProductID = 872;-- returns 324

UPDATE Production.ProductInventory SET Quantity=Quantity + 200 WHERE ProductID = 872; -- Blocks; ProductID 872 is locked!

The same SELECT will return 342 – the concurrent update is blocked!

COMMIT TRAN

-- unblocks and does the update

RESULT• NO NON-REPEATABLE READS

– GOOD!

• READERS BLOCK WRITERS– COULD BE A PROBLEM BECAUSE OF THE

LOWER CONCURRENCY

CAN USE THE SNAPSHOT ISOLATION LEVEL TO HAVE BOTH REPEATABLE READS AND READERS THAT DON’T

BLOCK WRITERS

HOW TO USE SNAPSHOT ISOLATION LEVEL

EXECUTE:

ALTER DATABASE <DATABASE_NAME>

SET ALLOW_SNAPSHOT_ISOLATION ON

NOW THE SAME with SNAPSHOT

<STIL> READ COMMITTED <STIL> SNAPSHOT

BEGIN TRAN BEGIN TRAN

SELECT Quantity FROM Production.ProductInventory WHERE ProductID = 872;-- returns 324

UPDATE Production.ProductInventory SET Quantity=Quantity + 200 WHERE ProductID = 872; -- Quantity latest version is now 524

SELECT Quantity FROM Production.ProductInventory WHERE ProductID = 872;-- returns 324 (the older version)

COMMIT TRAN

At this point, the SELECT if executed by this transaction will return 542 !!!

At this point, the SELECT if executed again will return 342 !!!

Update conflict in SNAPSHOT ISOLATION LEVEL

<STIL> SNAPSHOT

BEGIN TRAN BEGIN TRAN

SELECT Quantity FROM Production.ProductInventory WHERE ProductID = 872;-- returns 324

UPDATE Production.ProductInventory SET Quantity=Quantity + 200 WHERE ProductID = 872; -- Quantity is now 524

UPDATE Production.ProductInventory SET Quantity=Quantity + 300 WHERE ProductID = 872; -- Process will block

COMMIT TRAN

Process will receive error 3960

PHANTOMS EXAMPLE

<STIL> REPEATABLE READ <STIL> REPEATABLE READ

BEGIN TRAN BEGIN TRAN

SELECT Quantity FROM Production.ProductInventory WHERE ProductID > 998;-- returns 2 rows with ProductID 999

INSERT INTO ProductInventory(ProductID, ….) VALUES(999, ……) -- the row is inserted successfully

COMMITT TRAN

SELECT Quantity FROM Production.ProductInventory WHERE ProductID > 998;-- returns 3 rows with ProductID 999

-- the newly inserted is the phantom

SNAPSHOT vs. SERIALIZABLE

STIL SNAPSHOTUSE pubs DECLARE @price money BEGIN TRAN

STIL SNAPSHOTUSE pubs DECLARE @price moneyBEGIN TRAN

SELECT @price = priceFROM titles WHERE title_id = 'BU1032'

SELECT @price = priceFROM titles WHERE title_id = 'PS7777

UPDATE titles SET price = @priceWHERE title_id = 'PS7777'

UPDATE titles SET price = @priceWHERE title_id = 'BU1032

COMMIT TRAN COMMIT TRAN