1. Switch off your Mobiles Phones or Change Profile to Silent Mode

2. Database Concurrency

3. Concurrency 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.

4. Scenario 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

5. Scenario – Continued 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

6. Interleaved Transactions 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!!!

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

8. Lost Update Problem 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.

9. Lost Update – An Example 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 ?

10. Lost Update – An Example Correct balance after T A and T B should be 400!

11. Uncommitted Dependency Problem 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)

12. Uncommitted Dependency Problem 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 ?

13. Uncommitted Dependency– Example Correct balance after T A and T B should be 200!

14. Inconsistent Analysis Problem 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.

15. Inconsistent Analysis – Example Scenario: - room booking system T A is summing up the total number of vacant teaching rooms in 3 building (Tower, Moorgate and Eden), whilst T B is moving 2 classes (2 rooms) from Tower to Eden. Initial numbers of vacant rooms: Tower:10 Moorgate:15 Eden5 Total number30

16. 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

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

19. Objective of Concurrency Control 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

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

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

22. Transaction Schedule Two schedules are said to be equivalent if they are guaranteed to produce 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.

23. Concept of Serializability 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.

24. Locking 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.

25. Locking – the idea 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.

26. Two Types of Locks Exclusive Locks (X locks, 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. Shared Locks (S lock, 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.

27. Rules for Locking 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.

28. Rules for Locking 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.

29. Rules for Locking – Summary Compatibility Matrix

30. Locking Granularity 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

31. Two–Phased Locking 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

32. Lost Update Example Revisited 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

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

34. Deadlock Problem A system is in a state of Deadlock if there exists a set of transactions such that every transaction in the set is waiting for another transaction in the set. or Deadlock is a situation in which two or more transactions are in a simultaneous wait state, each of them waiting for one of the others to release a lock before it can proceed.

35. Deadlock Problem – Example Where p1 and p2 are data items At time t4, both transactions A and B are deadlocked and neither is able to proceed any further

36. Deadlock Handling Two main methods for deadlock handling Deadlock Prevention This method is used to ensure that the system will never enter a deadlock state. Deadlock Detection and Recovery This allows the system to enter a deadlock state then attempts to recover from it using a deadlock detection and recovery scheme. Both methods may result in transaction rollback and both incur overheads.

37. Deadlock Prevention Scheme Each transaction locks all its required data items before it begins execution. Either all data items needed are locked in one step (so the transaction can then proceed) or none are locked (to avoid locking only some of the data items needed) This scheme could be used if the probability of the system entering a deadlock state is relatively high (for long transactions needing many locks)

38. Deadlock Prevention Scheme Disadvantages of the scheme Low data utilisation Some data items could be locked for a long time before they are used. Possible starvation A transaction which requires a number of data items may find itself in a indefinite wait state while at least one of the data items is always locked by some other transactions. Note that there are other deadlock prevention schemes.

39. Deadlock Detection & Recovery Basic Idea The state of the system is examined periodically to detect whether a deadlock has occurred in the system If it has, the system attempts to recover from the deadlock (often involving rollback) This scheme is commonly used if the deadlock probability in the system is relatively low (for short transactions needing only a few data items)

40. Deadlock Detection & Recovery General Procedure Maintain information about the current allocation of data items to different transactions – namely, locks that have been granted Maintain information about any outstanding request for data items – namely locks that have been requested but not granted yet.

41. Deadlock Detection & Recovery Activate an algorithm (periodically or when required) which uses the above information to determine whether the system has entered a deadlock state If a deadlock state is entered (which may involve more than one deadlock), the system attempts to recover from the deadlock – namely, breaking the deadlock.

42. Deadlock Detection – WFG A Wait For Graph (WFG) can be used to detect a deadlock – a graph of who is waiting for whom WFG is a direct graph G = (N,E) which consists of a set of nodes N and a set of edges E Create a node for each transaction Create a directed edge Ti  Tj, if transaction Ti is waiting to lock an item which currently locked by Tj

43. Deadlock Detection – WFG When Tj releases the lock(s) on the items which Ti was waiting for, the directed edge is removed from the graph Deadlock exists if and only if the WFG contains a cycle

44. Deadlock Detection – WFG No Deadlock Yes Deadlock

45. Timing for Detection The question of when and how often the detection algorithm (e.g. WFG) should be invoked into action depends on several factors, including The number of transactions running in the system The waiting time of transactions The frequency of deadlock occurrences etc.

46. A Working Example of WFG Assumption The following list represents the sequence of event in an interleaved execution of a set of transactions T1, T2, … T7 in a concurrency system based on locking, where A, B, …. F are data items. Assume that FETCH A acquires an S lock on A, UPDATE A promotes that lock to an X lock, and all locks are held to the next synchpoint

47. A Working Example of WFG Question Provide a Wait–for–Graph to determaine whether there is a deadlock at time t17 and if so how the system could recover from the deadlock.

48. A Working Example of WFG

50. Deadlock Recovery After a deadlock situation has been identified, the system must try to recover from it. The most common solution is to rollback one or more transactions involved in the deadlock, so that deadlock can be broken Three issues to be addressed in deadlock recovery Issue of choosing a victim Issue of rollback operation Issue of Starvation

51. Deadlock Recovery – Three Issues Issue of choosing a victim Determine which transaction(s), among a set of deadlocked transactions, to be rolled back in order to break the deadlock. Criteria for choosing such a victim transaction often depends on cost factors. Issue of Rollback operation Determine how far the chosen victim transaction should be rolled back (total rollback or partial rollback)

52. Deadlock Recovery – Three Issues Issue of starvation Avoid situations where some transaction may always be chosen as the victim due to cost factors based selection, hence never completing its job.

53. Any Questions?