Database Systems: Transaction Management Query Processing September 98 Database Systems: Transaction Management 1

Necessity Database systems are normally being accessed by many users or processes at the same time. Both queries and modifications. Unlike Operating Systems, which support interaction of processes, a DMBS needs to keep processes away from troublesome interactions.

Example: Bad Interaction You and your father ( Joint A/c) each take Rs. 10,000 from different ATM’s at about the same time. The DBMS should make sure one account deduction doesn’t get lost. Comparison: An OS allows two people to edit a document at the same time. If both write, one’s changes get lost. What if the connection to the bank is lost during the transaction?

Transaction Management Support Chapter Name September 98 Transaction Management Support Two main issues to deal with: Concurrent execution of multiple transactions Failures of various kinds, such as hardware failures and system crashes 4

Transactions: Basic concepts A logical unit of database processing. An action or series of actions, carried out by user or application, which accesses or changes contents of database. Transforms database from one consistent state to another, although consistency may be violated during transaction. Transaction Processing System Systems with large databases and multiple concurrent users that are executing database transactions. Examples Banking systems, Airline reservations, Supermarket checkouts, ...

Database Access Operations Performed on a data item read-item (X) write-item (X) A transaction can have multiple database access operations. Each transaction has clearly specified beginning and end statements. A single application program may contain many transactions.

read-item (X), write-item (X) Read_item(X) includes steps: 1. Find the address of the disk block that contains the item X 2. Copy the disk block into a buffer in main memory 3. Copy the item X from the buffer to a program variable ( for simplicity also called X) Write_item(X) includes steps: 3. Copy the item X from a program variable into its correct location in the buffer 4. Store the updated block from the buffer back to disk

A Simple Transaction T1 T1: read and write sets of a Transaction read-item (X); X:= X + M; write-item (X); read and write sets of a Transaction read-set of T1 is {X} reads database item x into a program variable x write-set of T1 is also {X} writes program value of the variable x into the database item x

Another example read_item(X); X:=X-N; write_item(X); read_item(Y); read_item(Z); Y:=Y+Z+N; write(Y); read_set of T2 is {X,Y,Z}, write_set of T2 is {X,Y}

Transaction Operations A transaction is either completed in its entirely or not done at all. Hence for recovery purpose, the recovery manager keeps track of the following transaction operations. begin-transaction read-item write-item end-transaction commit abort (or rollback)

Transaction States Active Partially Committed Committed Failed read-item, write-item begin-transaction end-transaction Active Partially Committed commit Committed abort abort Failed Terminated STATE Transition

Commit Point of a Transaction T Marks the successful completion of T and having recorded the effect of all the transaction operations on the database in the system log. [Commit, T] is recorded in the system log [start-transaction, T1] … ... [start-transaction, T2] [commit, T2] [commit, T1]

Rollback Point of a Transaction T Causes the transaction to end, but by aborting. No effects on the database. [Rollback, T] is recorded in the system log Failures like division by 0 can also cause rollback, even if the programmer does not request it [start-transaction, T1] … ... [start-transaction, T2] [commit, T2] [rollback, T1]

Desirable properties: ACID Transactions should possess ACID properties. ACID properties should be enforced by concurrency control and recovery methods of the DBMS Atomicity – Either the whole process is done or none is.. Consistency Preservation – Database constraints are preserved.. Isolation – It appears to the user as if only one process executes at a time. Durability – Effects of a committed process do not get lost if the system crashes.

Why Concurrency Control is needed? Transaction processing systems are large databases with multiple users executing database transactions Multiple users are concurrently executing transactions A transaction can have several data access operations, some of which could be accessing the same data item

Contd… Simultaneous execution of transactions over a shared database can create several data integrity and consistency problems. Transactions could be run serially, but this limits the degree of concurrency or parallelism in system. Although two transactions may be correct in themselves, interleaving of operations may produce an incorrect result.

!!! Concurrency Problems Lost update Dirty read Incorrect summary Unrepeatable Read

Item X has an incorrect value because its update by T1 is lost Lost Update Two transactions have their operations interleaved in such a way that it makes the value of some data items incorrect T1 read-item (X); X:=X-N; write-item (X); read-item (Y); Y:=Y+N; write-item (Y); T2 read-item (X); X:=X+M; write-item (X); Item X has an incorrect value because its update by T1 is lost

The update of the item x by T1 is lost Lost update T i m e T1 T2 r[x] x:=x+1 x:=x-1 w[x] r[y] y:=y-1 w[y] x=5 x:=6 x:=4 x=6 x=4 y=2 y:=1 y=1 The update of the item x by T1 is lost

Dirty read (temporary update) A transaction updates a database item and then fails. The updated item is accessed by another transaction before it is restored back to its original value T1 read-item (X); X:=X-N; write-item (X); read-item (Y); Abort; T2 read-item (X); X:=X+M; write-item (X); T1 fails and must restore the value of X; meanwhile T2 has read the temporary incorrect value of X

Dirty read (temporary update) T1 T2 r[x] x:=x+1 w[x] x:=x+2 r[y] Abort T1 x=5 x:=6 x=6 x:=8 x=8 r[y] The value of x written to the database is equal to: initial value of x + 3, while it should be x+2

Incorrect summary A transaction aggregating a number of records may read values of some records before, and some after the update by another transaction T3 sum:=0; read-item(A) sum:=sum+A; . read-item (X); sum:=sum+X; read-item (Y); sum:=sum+Y; T1 read-item (X); X:=X-N; write-item (X); read-item (Y); Y:=Y+N; write-item (Y); T3 reads X after N is subtracted, and reads Y before N is added; a wrong summary is calculated

Unrepeatable read A transaction reads the value of an item twice, and the value of the item is changed by another transaction in between the reads T1 read-item (X); read-item (X) X:=X-N; write-item (X); T2 read-item (X); X:=X+M; write-item (X); T1 reads X again, however T2 has changed the value of X after the first read

Unrepeatable read T1 T2 r[x] x:=3*x w[x] x:=x+2 r[y] y:=y+x/2 w[y] x=4 Value of x used in T1 to compute the update of y is not the value of x expected to be used

Why Recovery is needed? Two types of storage: volatile (main memory) and nonvolatile. Volatile storage does not survive system crashes. Reasons for the need of recovery Physical problems and catastrophes Disk failure System failure Transaction failure Local error or exception condition Concurrency control enforcement. The system must keep sufficient information to recover from the failure. DBMS should commit changes for successful transactions and reject changes of aborted transactions.

Desirable properties: ACID Transactions should possess ACID properties. ACID properties should be enforced by concurrency control and recovery methods of the DBMS Atomicity – Either the whole process is done or none is.. Consistency Preservation – Database constraints are preserved.. Isolation – It appears to the user as if only one process executes at a time. Durability – Effects of a committed process do not get lost if the system crashes.

Schedules A Schedule is the order of execution of operations from various transactions. A formal definition of a schedule is: A schedule S of n transactions T1, T2, …, Tn is an ordering of the operations of these transactions, given that  Ti  S, the order of operations of Ti in S is the same as in the original Ti. Schedules consider read-item, write-item, commit and abort operations only and the order of operations in S to be a total order.

Example Schedule Sa : r1 (X); r2 (X); w1 (X); r1 (Y); w2 (X); w1 (Y); Notation r read-item w write-item c commit a abort r1 (X) T1: read-item (X) a2 T2: abort T1 read-item (X); X:=X-N; write-item (X); read-item (Y); Y:=Y+N; write-item (Y); T2 read-item (X); X:=X+M; write-item (X);

Characterising Schedules Based on Recoverability For some types of schedules it is easy to recover but not for all. Characterise the type of schedules for which recovery is possible and relatively simple: Recoverable and nonrecoverable schedules Cascadeless or Avoid cascading rollback (ACR) schedules Strict schedules

Recoverable Schedules Schedules that can recover from transaction failures such that once a transaction is committed it should never be necessary to roll back. Non recoverable schedules should not be permitted for execution. Formally A schedule S is recoverable if no transaction T in S commits until all transactions T` that write an item that T reads, have committed.

Examples of Recoverable Schedules Sc: r1(X); w1(X); r2(X); r1(Y); w2(X); c2; w1(Y); a1; T2 reads item X fromT1 and then T2 commits before T1 commits. If T1 aborts after c2 then X that T2 read is no longer valid and T2 must be aborted after it has been committed. - Non-recoverable Schedule Sd: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); c1; c2; - Recoverable Schedule

More Examples Consider the following schedules for two transaction with interleaved execution. S1: r1[x], r2[y], w1[x], w2[y], r2[x], w2[x], c2, r1[y], a1 S2: r1[x], r2[y], r1[y], w2[y], w1[x], r2[x], w2[x], c1, c2 S1 is not recoverable since T2 reads item x written by the transaction T1 that failed. S2 is recoverable; i.e. T2 reads items written by T1 and does not commit before T1. In a recoverable schedule, no committed transaction ever needs to be rolled back.

Cascading Rollback T8 T5 T7 T3 T9 T4 T6 T2 T1 An uncommitted transaction has to be rolled back because it reads an item from a transaction which failed. It can be time consuming! T8 T5 T3 T2 T6 T7 T9 T4 Suppose that T5 has to be aborted. All transactions ‘reachable’ from T5 are aborted. T1

Cascadeless or ACR Schedules Cascadeless schedules are recoverable schedules that avoid cascading rollbacks. A cascadeless schedule is guaranteed not to be rolled back. Formally A schedule S is cascadeless if every transaction reads only items that were written by committed transactions.

Examples of Cascadeless Schedules Recoverable Schedule with cascading rollback Se: r1(X); w1(X); r2(X); r1(Y); w2(X); w1(Y); a1; a2; T2 has to be rolled back because it reads X from T1 and T1 then aborted, Cascadeless Schedule ( delaying T2) Sf: r1(X); w1(X); a1; r2(X); w2(X); c2;

Strict Schedules Strict schedules are recoverable and cascadeless schedules that guarantee correct results. Strict schedules simplify the recovery process. Formally A schedule S is strict if transactions can neither read nor write an item X until the last transaction that wrote X has committed (or aborted).

Examples of Strict Schedules Recoverable and Cascadeless Schedule with potential incorrect results. Sg: r1(X); w1(X); w2(X); a1; - not a strict schedule because T2 writes X before T1 commits or aborts that last wrote X. Strict Schedule Sh: r1(X); w1(X); a1; w2(X);

Characterization of Schedules Avoidance of cascading rollback Recoverability Strictness

Characterising Schedules Based on Serializability Characterise the type of schedules that are considered correct when concurrent transactions are executing. Serial schedules Nonserial schedules Conflict-Serializable schedules

Serial Schedules Schedules that execute each transaction one by one without any interleaving. Formally A schedule S is serial if for every transaction T participating in S, all operations of T are executed consecutively; otherwise the schedule is called nonserial. There are n! serial schedules for n transactions A serial schedule is always correct, but unacceptable in practice !

Examples of Serial Schedules Serial Schedules (a) T1 read-item (X); X:=X-N; write-item (X); read-item (Y); Y:=Y+N; write-item (Y); T2 X:=X+M; Serial Schedules (b) T1 read-item (X); X:=X-N; write-item (X); read-item (Y); Y:=Y+N; write-item (Y); T2 X:=X+M;

Examples of Nonserial Schedules T1 read-item (X); X:=X-N; write-item (X); read-item (Y); Y:=Y+N; write-item (Y); T2 X:=X+M; Non-serial Schedules (c) Non-serial Schedules (d) T1 read-item (X); X:=X-N; write-item (X); read-item (Y); Y:=Y+N; write-item (Y); T2 X:=X+M;

Results of Example Schedules Initial Values of database items X = 90, Y =90, N = 3, M = 2 Results: Schedule (a): Y = 93, X =89 Schedule (b): Y = 93, X =89 Schedule (c): Y = 93, X =92 Schedule (d): Y = 93, X =89 We are interested in schedule like the schedule (d).

Serializable Schedules A serializable schedule is a nonserial schedules that is equivalent to some serial schedule. it gives the correct result in spite of interleaving. Formally A schedule S of n transactions is serializable if it is equivalent to some serial schedule of the same n transactions When are two schedules ‘equivalent’?

Schedule equivalence Conflict Equivalence View Equivalence The order of any two conflicting operations is the same in both schedules. View Equivalence Each read operation of a transaction reads the result of the same write operation in both schedules. Result Equivalence The two schedules produce the same final state of the database. Other types of Equivalence

Conflict Equivalence and Conflicting Operations Schedules are called conflict equivalent if the order of any two conflicting operations is same in both schedules. Operations of a schedule are in Conflict if they satisfy all of the following conditions: they belong to different transactions; they access the same item X; and at least one is a write-item (X). An example Sa : r1 (X); r2 (X); w1 (X); r1 (Y); w2 (X); w1 (Y); the Conflicting operations are: {r1(X) and w2(X)}, {r2(X) and w1(X)}, {w2(X) and w1(X)} but {r1(X) and r2(X)}, {w1(X) and w2(Y)} are not in conflict.

Example of Conflict Equivalence Consider two schedules: S1: …. r1(X); w2(X); ….; S2: …. w2(X); r1(X); ….; S1 and S2 are not conflict equivalent. r1(X) and w2(X) are conflicting operations of transactions T1 and T2. Value read by r1(X) can be different in the two schedules.

Conflict Serializable A schedule S is conflict serializable if it is conflict equivalent to some serial schedule S`. T1 read-item (X); X:=X-N; write-item (X); read-item (Y); Y:=Y+N; write-item (Y); T2 X:=X+M; Serial Schedule S`: … w1(X);…; r1(X);…; T1 read-item (X); X:=X-N; write-item (X); read-item (Y); Y:=Y+N; write-item (Y); T2 X:=X+M; Conflict Serializable Schedule S: … w1(X); r1(X);…;

Precedence Graph Precedence Graph is used to test for serializability A directed graph G = (N, E), where N is a set of Nodes, N = {T1, T2, …, Tn} E is a set of directed edges, E = {e1, e2, …, em} Each transaction Ti in the schedule has one node Each edge ei is (Tj  Tk) 1  j  n, 1  k  n The edge ei is created when an operation in Tj is followed by a conflicting operation in Tk The schedule S is serializable iff the graph has no cycles A path is called a cycle if it starts and ends in the same node and contains at least two nodes. If the precedence graph contains cycle, the schedule is not conflict serializable.

Precedence Graph for a Serial Schedule T1 read-item (X); X:=X-N; write-item (X); read-item (Y); Y:=Y+N; write-item (Y); T2 X:=X+M; Serial Schedule Sa: … w1(X);…; r2(X);…; T1 T2 X Precedence Graph for Sa

Precedence Graph for a Serializable Schedule T1 read-item (X); X:=X-N; write-item (X); read-item (Y); Y:=Y+N; write-item (Y); T2 X:=X+M; Conflict Serializable Schedule Sb: … w1(X); r2(X);…; T1 T2 X Precedence Graph for Sb

Precedence Graph for a Non-Serializable Schedule Sc:.. r2(X);..w1(X);..w2(X);..; X T1 read-item (X); X:=X-N; write-item (X); read-item (Y); Y:=Y+N; write-item (Y); T2 X:=X+M; T1 T2 X Precedence Graph for Sc

Precedence Graph: More complex example r1[x], r5[z], r2[y], r2[x], r3[q], r4[s], r4[u], w2[x], w3[q], r1[t], r5[s], w4[u], w2[y], w5[z], r3[t], r1[q], r2[t], r5[x], r4[y], r3[u], r3[z], r1[p], r1[s], r3[p], w3[p], w5[x], w1[p], w1[q] 1 2 5 4 3

Example…cont. r1[x], w1[x], r5[z], r2[y], r2[x], r3[q], r4[s], r4[u], w2[x], w3[q], r1[t], r5[s], w4[u], w2[y], w5[z], r3[t], r1[q], r2[t], r5[x], r4[y], r3[u], r3[z], r1[p], r1[s], r3[p], w3[p], w5[x], w1[p], w1[q] 2 1 3 4 5

Example…cont. r1[x], w1[x], r5[z], r2[y], r2[x], r3[q], r4[s], r4[u], w2[x], w3[q], r1[t], r5[s], w4[u], w2[y], w5[z], r3[t], r1[q], r2[t], r5[x], r4[y], r3[u], r3[z], r1[p], r1[s], r3[p], w3[p], w5[x], w1[p], w1[q] 2 1 3 4 5

Example…cont. r1[x], w1[x], r5[z], r2[y], r2[x], r3[q], r4[s], r4[u], w2[x], w3[q], r1[t], r5[s], w4[u], w2[y], w5[z], r3[t], r1[q], r2[t], r5[x], r4[y], r3[u], r3[z], r1[p], w1[p], r1[s], r3[p], w3[p], w5[x], w1[p], w1[q] 2 1 3 4 5

Example…cont. 2 1 3 4 5 Is it serializable? r1[x], w1[x], r5[z], r2[y], r2[x], r3[q], r4[s], r4[u], w2[x], w3[q], r1[t], r5[s], w4[u], w2[y], w5[z], r3[t], r1[q], r2[t], r5[x], r4[y], r3[u], r3[z], r1[p], w1[p], r1[s], r3[p], w3[p], w5[x], w1[p], w1[q] 2 1 3 4 5 Is it serializable?

Concurrency Control: What? Process of managing simultaneous operations on the database without having them interfere with one another. Prevents interference when two or more users are accessing database simultaneously and at least one is updating data. - obtaining serializable schedules.

Concurrency Control Protocols Testing for serializability after execution is meaningless. Practical solution is to provide methods for ensuring serializability without performing serializability testing. Commercially accepted protocols Locking and Timestamps Both are conservative approaches: delay transactions if they conflict with other transactions. Other protocols Optimistic These methods assume conflict is rare: allow transactions to proceed unsynchronised, and only check for conflicts at commit.

Locking Locking is used to synchronize access by concurrent transactions on data items. Transaction uses locks to deny access to other transactions and so prevent incorrect updates. A lock is a variable for a data item, that describes the status of the item with respect to allowable operations. Example: Locking an item X for writing, prohibits other transactions from issuing a write-item (X).

Types of Locks Binary Locks Read/Write Locks Simple but too restrictive Read/Write Locks Used in commercial DBMSs

Binary Locks A binary lock can have 2 states: Locked (or 1) Unlocked (or 0) LOCK (X) has the current value of the binary lock on an item X. Item X is locked when LOCK (X) = 1 Item X is unlocked when LOCK (X) = 0 When LOCK(X) = 1, other database transactions cannot perform data access operations on X.

Binary Locking Operations lock-item (X) B: if LOCK (X) = 0 then LOCK (X) := 1 else begin wait (until LOCK (X) = 0 and lock manager wakes the transaction); go to B; end; unlock-item (X) LOCK (X) := 0; wakeup one of the waiting transactions if any;

Binary Locking Scheme 1. A transaction T must issue lock-item (X) before any read-item (X) or write-item (X). 2. A transaction must issue unlock-item (X) after completing all read-item (X) and write-item (X). 3. A transaction T will not issue a lock-item (X) if T already holds the lock on X. 4. A transaction T will not issue unlock-item (X) unless it holds the lock on X.

Implementing Binary Locks DBMS has a lock manager sub-system that keeps track of locks. Lock manager maintains: A record of all locked items; (Item-name, LOCK, Locking-transaction) A queue of waiting transactions.

Shared/Exclusive LockingOperations Mutual exclusion enforced by binary locks is too restrictive. Several transactions should be allowed to access X for reading. A read/write lock can have 3 states: read-lock (shared-lock) cannot conflict, so more than one transaction can hold read locks simultaneously on the same item. write-lock (exclusive-lock) gives a transaction exclusive access to that item. unlock A record of locked items is maintained with the following fields: (item-name, LOCK, no-of-reads, locking-transaction(s)).

Read/Write Locking Operations unlock-item (X) B: if LOCK (X) := ‘unlocked’ then begin LOCK (X) := ‘read-locked’; no-of-reads := 1; end else if LOCK (X) = ‘read-locked’ no-of-reads := no-of-reads (X)+1; else wait (until LOCK (X) = ‘unlocked’ and lock manager wakes the transaction; go to B; end; read-lock (X) write-lock (X) if LOCK (X) := ‘write-locked’ then begin LOCK (X) := ‘unlocked’; wakeup; end else if LOCK (X) = ‘read-locked’ no-of-reads := no-of-reads (X)-1; if no-of-reads (X) = 0 LOCK (X) = ‘unlocked’; end; B:if LOCK (X) = ‘unlocked’ then LOCK (X) := ‘write-locked’ else begin wait (until LOCK (X) = ‘unlocked’ and lock manager wakes the transaction; go to B; end;

Read/Write Locking Scheme 1. A transaction T must issue read-lock (X) or write-lock before any read-item (X). 2. A transaction T must issue write-lock (X) before any write-item (X). 3. A transaction must issue unlock-item (X) after completing all read-item (X) and write-item (X). 4. A transaction T will not issue a read-lock (X) if T already holds a read/write lock on X. 5. A transaction T will not issue write-lock (X) if T already holds a read/write lock on X. 6. A transaction T will not issue unlock (X) unless it already holds a read/write lock on X.

Shared/Exclusive Locking Scheme: Example T1: r(y); r(x); x:=x+y; w(x). T2: r(x); r(y); y:=y+x; w(y). T1 read_lock[y] r[y] unlock[y] write_lock[x] r[x] x:=x + y w[x] unlock[x] T2 read_lock[x] r[x] unlock[x] write_lock[y] r[y] y := x + y w[y] unlock[y]

Shared/Exclusive Locking Scheme: Example T1 read_lock[y] r[y] unlock[y] write_lock[x] r[x] x:=x + y w[x] unlock[x] T2 read_lock[x] r[x] unlock[x] write_lock[y] r[y] y := x + y w[y] unlock[y] Initial Values: X = 20, Y = 30 Two serial schedules using locks: A: T1 followed by T2: X = 50, Y = 80. B: T2 followed by T1: X = 70, Y = 50.

A nonserial schedule using locks T1 read-lock (Y); read-item (Y); unlock (Y); write-lock (X); read-item (X); X:=X+Y; write-item (X); unlock (X); T2 read-lock (X); read-item (X); unlock (X); write-lock (Y); read-item (Y); Y:=X+Y; write-item (Y); unlock (Y); X unlocked too early Final state: X = 50, Y = 50 A Nonserializable schedule Y unlocked too early Problem: Transactions release locks too soon, resulting in the loss of total isolation and atomicity.

Guaranteeing Serializability: Two-Phase Locking Protocol Locking alone does not ensure serializability ! Positioning the locking and unlocking operations in interleaved transactions is the key task. To guarantee serializability, an additional protocol concerning the positioning of lock and unlock operations in every transaction is needed. Two-Phase Locking Protocol (2PL)

Two-Phase Protocol A transaction follows the two-phase protocol if all locking operations precede the first unlocking operation. Phase 1: Growing read-lock (X) write-lock (X) write-lock (Y) Phase 2: Shrinking unlock (X) unlock (Y)

Shared/Exclusive Locking Scheme: Example T1 read_lock[y] r[y] write_lock[x] unlock[y] r[x] x:=x + y w[x] unlock[x] T2 read_lock[x] r[x] write_lock[y] unlock[x] r[y] y := x + y w[y] unlock[y] Two transactions obeying two-phase locking

The Lost update problem T i m e T1 T2 r[x] x:=x+1 x:=x-1 w[x] r[y] y:=y-1 w[y] x=5 x:=6 x:=4 x=6 x=4 y=2 y:=1 y=1 The update of the item x by T1 is lost

The update of the item x by T1 is not lost Preventing Lost Update problem using 2PL T1 T2 write_lock[x] r[x] x:=x+1 wait w[x] wait write-lock[y] unlock[x] wait x:=x-1 w[x] unlock[x] r[y] y:=y-1 w[y] unlock[y] The update of the item x by T1 is not lost

The Dirty read (temporary update) Problem T1 T2 r[x] x:=x+1 w[x] x:=x+2 r[y] Abort T1 x=5 x:=6 x=6 x:=8 x=8 r[y] The value of x written to the database is equal to: initial value of x + 3, while it should be x+2

Preventing Temporary Update problem using 2PL T1 T2 write_lock[x] r[x] x:=x+1 w[x] wait Abort T1 x:=x+2 unlock[x] The value of x written to the database is equal to: initial value of x plus 2

Variants of Two-Phase Protocol Basic Locking operations precede the first unlocking operation. Conservative Locking operations precede transaction execution. Strict Unlocking of write-locks after commit (or abort). Rigorous Unlocking of all locks after commit (or abort).

Limitations of two-phase Some serializable schedules may not be permitted. Locking in general, may cause Deadlocks and Starvation.

Deadlocks Each transaction in a set (of >=2 transactions) is waiting for an item which has locked another transaction in the set. T1 read-lock (Y); read-item (Y); write-lock (X); T2 read-lock (X); read-item (X); write-lock (Y); Partial Schedule S T1 T2 Wait-for Graph for S

Dead Lock Handling Only one way to break deadlock: abort one or more of the transactions. Deadlock should be transparent to user, so DBMS should restart the aborted transactions later.

Dead Lock Handling contd.. Two general techniques for handling deadlock: Deadlock prevention DBMS looks ahead to see if transaction would cause deadlock, and never allows deadlock to occur. Deadlock detection and recovery DBMS allows deadlock to occur but recognizes it and breaks it.

Deadlock Prevention Protocols Conservative: Every transaction requires all locks before it starts. This is a serious limitation of the concurrency. If one lock is not available, the whole process waits.

contd.. 2. Another protocol Ordering all the items in the database. Lock the items according to that order if a transaction needs several items. Also limits the concurrency. This also requires that the programmer must be aware about the chosen order of items.

Deadlock Prevention: Using Timestamps Transaction Timestamps – unique identifier assigned to each transaction. Ti wants to lock an item which is currently locked by Tj Wait-die – if TS(Ti)<TS(Tj) (Ti is older than Tj), then Ti is allowed to wait; otherwise (Ti younger than Tj) abort Ti and restart it later with the same timestamp. only an older transaction can wait for younger one, otherwise transaction is aborted (dies) and restarted with same timestamp.

Deadlock Prevention: Using Timestamps Ti wants to lock an item which is currently locked by Tj Wound-wait – if TS(Ti)<TS(Tj) (Ti is older the Tj), then abort Tj (Ti wounds Tj) and restart it later with the same timestamp; otherwise (Ti younger than Tj) Ti is allowed to wait. only a younger transaction can wait for an older one. If older transaction requests lock held by younger one, younger one is aborted (wounded).

Deadlock Detection Wait-for graphs showing transaction dependencies Create a node for each transaction. Create an edge Ti -> Tj, if Ti is waiting to lock the item locked by Tj. Deadlock exists if and only if WFG contains cycle. WFG is created at regular intervals. Dynamic process - drop/create links. Perform system check based on given parameters.

Contd.. Abort deadlock causing transactions through a ‘victim selection’ algorithms. Problem – when to check for the deadlock? A practical solution - Timeouts Abort transactions waiting for a period longer than the system defined ‘time out’ period ( regardless of deadlock!) .

Starvation A transaction waits indefinitely, while others continue normally. Usually the result of an unfair waiting scheme Prevention Schemes First come first served queue for locking requested items Dynamic priority increase for waiting transactions or repeated ‘victims’