1. Academic Year 2014 Spring Academic Year 2014 Spring

2. MODULE CC3005NI: Advanced Database Systems “DATABASE CONCURRENCY” (PART – 1) Academic Year 2014 Spring Academic Year 2014 Spring

3.  Database Systems typically allow multiple users to access shared data concurrently.  Concurrency Control is critical in ensuring that concurrent operations are carried out correctly and efficiently. Concurrency:

4.  A transaction typically involves a series of I/O operations (handled by I/O subsystem) and other processing operations (handled by CPU).  Assume that Transactions T A and T B performs a series of processing (sub-tasks) T A1, T A2, T A3 and T B1, T B2, T B3 respectively.  Assume that CPU is shared by T A and T B and other transactions in the system Scenario:

5.  In a single transaction environment:  TA is run in the following sequence  In a multi transaction environment:  TA and TB may be run in the following sequence due to shared CPU T A1 T A2 T A3 T A1 T B1 T B2 T A2 T A3 T B3 Scenario (continued) :

6.  The operations of the two transactions TA and TB are said to be interleaved to achieve concurrent execution.  Interleaved sequence of transactions: T A1 T B1 T A2 T B2 T A3 T B3  A more realistic environment may involve hundreds and thousands of transactions running concurrently, sharing CPUs in the system.  Various concurrency problems may occur if proper control is not enforced. Interleaved Transactions:

7.  There are three Concurrency Problems (three types of potential mistakes) which could occur in an interleaved transaction environment  Lost update  Uncommitted dependency  Inconsistent analysis Concurrency Problems:

8.  This relates to a situation where two concurrent transactions, say T A and T B, are allowed to update an uncommitted change on the same data item, say x.  The earlier update of x by Transaction T A is overwritten by a subsequent update of x by transaction T B.  Consequently, the update value of x by T A is lost after the update by T B. 1. Lost Update Problem:

9.  So, T A ‘s update at t4 is lost after T B ‘s update at t5.  What should be the correct balance after T A and T B ? 1. Lost Update Problem - Example:

10.  Correct balance after T A and T B should be 400 1. Lost Update Problem - Example:

11.  This relates to a situation when one transaction T A is allowed to retrieve or update a data item which has been updated by another transaction T B that has not yet committed.  If that transaction T B is subsequently Rolled Back, the transaction T A will have used some Unsafe or Uncommitted data values produced by T B (now aborted) 2. Uncommitted Dependency Problem :

12.  So, T B has used an uncommitted result produced at t4 by a later aborted transaction T A  What should be the correct balance after T A and T B ? 2. Uncommitted Dependency - Example :

13.  Correct balance after T A and T B should be 200 2. Uncommitted Dependency - Example :

14.  This relates to a situation when a transaction T A reads several data values from a database but another transaction T B updates some of them during the execution of T A.  In fact, transaction T A has seen an inconsistent state of the database during its execution (caused by transaction T B ‘s access), and therefore performed an Inconsistent Analysis. 3. Inconsistent Analysis Problem :

15.  Scenario: - ROOM BOOKING SYSTEM  TA is summing up the total number of vacant teaching rooms in 3 building (Tower, Moorgate and Eden), whilst TB is moving 2 classes (2 rooms) from Tower to Eden.  Initial numbers of vacant rooms: Tower:10 Moorgate:15 Eden:5 Total number:30 3. Inconsistent Analysis - Example :

17.  Initial numbers of vacant rooms: Tower:10 Moorgate:15 Eden5  Correct numbers of vacant rooms after moving should be: Tower:8 (10 – 2) Moorgate:15 Eden7 (5+2)  But we seem to have got 32 vacant rooms now!!! WRONG TOTAL Total Number: 30 3. Inconsistent Analysis - Example :

18.  Discussed enough problems Let’s find a solution!! Solution:

19.  The objective of concurrency control is to:  Schedule multiple transactions in such a way as to avoid any interference between them, while at the same time  Maximize the degree of concurrency or parallelism in the system Objective of Concurrency Control:

20.  Serialization  Permit serial execution of transactions o One transaction must commit before another can start.  Inefficiency for multi-user database environment! Solutions to the Concurrency Problems:

21.  Concurrency Control  Allow concurrent execution of transactions, in a controlled way  Three mechanisms can be used o Locking (which we will focus on) o Optimistic Scheduling o Time stamping Solutions to the Concurrency Problems:

22.  Two schedules are said to be equivalent if they are guaranteed to the same result.  Therefore, if a set of transactions executes concurrently, the interleaved schedule is correct if it produces the same results as some serial execution.  Such an interleaved schedule is said to be serializable. Transaction Schedule:

23.  A given execution of a set of transactions is considered to be correct if it is serializable  If it produces the same result as some serial execution of the same transactions, running them one at a time.  Serializability is the generally accepted criterion for correctness for the execution of a given set of concurrent transactions. Concept of Serializability:

24.  Locking method is the most commonly used approach to ensure serializability of concurrent transactions.  Locking synchronizes interleaved transactions so that it is equivalent to some serial execution of those transactions. Locking:

25.  The idea of ensuring serializability by locking is simple:  When a transaction requires the assurance that some data will not change during the course of processing (read/write) it, this transaction must request and acquire a lock, in order to prevent other transactions updating the data. Locking – the Idea:

26. X locks  Exclusive Locks ( X locks, or write locks)  Grant read/write access to a data item to the transaction which holds the lock  Prevent any other transactions reading or writing the same data item. S locks  Shared Locks ( S locks, or read locks)  Grant read only access to a data item to the transaction which holds the lock  Prevent any transaction writing data item.  Several transactions may hold a S lock on the same data item. Two Types of Locks:

27.  Locking Protocol  A transaction must get an S lock on a data item before it wishes to read it  A transaction must get an X lock on a data item before it wishes to write it  A transaction already holding an S lock on a data item can promote itself to an X lock in order to write it, provided there is no other transaction also holding an S lock on it already. Rules of Locking:

28.  If a lock request is denied, the transaction goes into a wait state  A transaction in a wait state resumes operations only when the requested lock is released by another transaction  X locks are held until commit/rollback. S locks are normally the same. Rules of Locking:

29.  Compatibility Matrix Rules of Locking - Summary:

30.  The size of a data object to be locked is referred to as the locking granularity. It could be, for example  A single data value  Tuple(s) or column(s) in a relation  Several relations  Entire database, etc.  Larger the data object being locked, lower degree of concurrency in system Locking Granularity:

31.  Two–Phased locking protocol:  Before operating on any object (a tuple), a transaction must acquire a lock on that object  After releasing a lock a transaction must never go on to acquire any more locks.  Two–Phased locking theorem:  If all transactions obey the “two–phased locking protocol”, then all possible interleaved schedules are serializable Two-Phased Locking:

32.  Now, neither transaction can update ‘balance’ as both are waiting for other to release the lock on ‘balance’  Although lost update problem is avoided, locking in this situation has created another new problem: DEADLOCK Lost Update Example Revisited:

33.  So the final balance is 200 - CORRECT Uncommitted Dependency Example Revisited:

34. Thank you!!! Questions are WELCOME Academic Year 2014 Spring Academic Year 2014 Spring