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 Atomicity Each 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 Consistency A transaction won't allow the system to arrive at an incorrect logical state. The data must always be logically correct.

ACID Properties Isolation Separates concurrent transactions from the updates of other incomplete transactions Accomplished automatically using locking or row versions

ACID Properties 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 reads When 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 READ COMMITTED READ UNCOMMITTED BEGIN TRAN SELECT Quantity FROM Production.ProductInventory WHERE ProductID = 872; -- returns 324 UPDATE Production.ProductInventory SET Quantity=Quantity 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) READ COMMITTED BEGIN TRAN SELECT Quantity FROM Production.ProductInventory WHERE ProductID = 872; -- returns 324 UPDATE Production.ProductInventory SET Quantity=Quantity 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 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 READ COMMITTED BEGIN TRAN SELECT Quantity FROM Production.ProductInventory WHERE ProductID = 872; -- returns 324 UPDATE Production.ProductInventory SET Quantity=Quantity 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 READ COMMITTED REPEATABLE READ BEGIN TRAN SELECT Quantity FROM Production.ProductInventory WHERE ProductID = 872; -- returns 324 UPDATE Production.ProductInventory SET Quantity=Quantity 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 SET ALLOW_SNAPSHOT_ISOLATION ON

NOW THE SAME with SNAPSHOT READ COMMITTED SNAPSHOT BEGIN TRAN SELECT Quantity FROM Production.ProductInventory WHERE ProductID = 872; -- returns 324 UPDATE Production.ProductInventory SET Quantity=Quantity 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 SNAPSHOT BEGIN TRAN SELECT Quantity FROM Production.ProductInventory WHERE ProductID = 872; -- returns 324 UPDATE Production.ProductInventory SET Quantity=Quantity WHERE ProductID = 872; -- Quantity is now 524 UPDATE Production.ProductInventory SET Quantity=Quantity WHERE ProductID = 872; -- Process will block COMMIT TRAN Process will receive error 3960

PHANTOMS EXAMPLE REPEATABLE READ 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 the newly inserted is the phantom

SNAPSHOT vs. SERIALIZABLE STIL SNAPSHOT USE pubs money BEGIN TRAN = price FROM titles WHERE title_id = 'BU1032' = price FROM titles WHERE title_id = 'PS7777 UPDATE titles SET price WHERE title_id = 'PS7777' UPDATE titles SET price WHERE title_id = 'BU1032 COMMIT TRAN