1. TRANSACTION MANAGEMENT R.SARAVANAKUAMR. S.NAVEEN.

2. Transactions A transaction is a sequence of operations that perform a single logical task. The database must be in a consistent state before and after a transaction but may become inconsistent during execution. Transaction management ensures that the database can be restored to a consistent state if something goes wrong during the transaction.

3. Transaction Concepts Structure of a Transaction Begin transaction Read input message Perform processing against database If successful send output message(s) and COMMIT else send error message and ROLLBACK End transaction Transfer Rs.500 from savings account to checking account. Begin transaction Read Sav_Amt Sav_Amt := Sav-Amt - 500 Write Sav_Amt Read Chk_Amt Chk_Amt := Chk_Amt + 500 Write Chk-Amt End transaction

4. ACID Properties of a Transaction Atomicity – either all or none of the operations of a transaction are performed. Consistency – Data Base is in a consistent state before and after a executing a transaction (may be inconsistent during execution). Isolation – Transactions are isolated from one another. Durability – Once transaction commits, the changes it has made to Data Base persist, even if system fails.

5. Transaction access data using two operation Read(x) – Which transfers the data item x from the database to local buffer belonging to the transaction that executed the read operation. Write (x) – Which transfers the data item x from the local buffer to the transaction that executed the write back to the database If the database operations in a transaction do not update the database but only retrieve data, the transaction is called a read-only transaction.

6. Transaction states Active Partially Committed Failed Committed Aborted

7. Transaction States Active: Initial state; when the transaction is executing Partially Committed: When the last statement has finished execution Failed: On discovery that normal execution can no longer proceed Aborted: After the rollback is performed from a failed transaction Committed: After successful completion Terminated: Aborted

8. Shadow Copy  A transaction that wants to update the database first create a complete copy of the database. All updates are done on the new database copy, leaving the original copy.  If at any point the transaction has to be aborted, the system merely deletes the new copy. The old copy of the database has not been affected.

9. Concurrent Executions  Improve throughput & Resource Utilization : Throughput : The Number of transaction Executed in a given amount of time. Resource Utilization : The processor and Disk utilization  Reduced Waiting time: The average time for a transaction to be completed after it has been submitted.

10. Serializability Transaction T1: read (A) A = A – 50; write (A) read (B) B = B + 50; write (B) Transaction T2: read (A) t = A * 0.1; A = A – t; write (A) read (B) B = B + t; write (B) On executing a set of concurrent transactions on a database the net effect should be as though the transactions were executed in some serial order.

11. Good schedule T1 T2 read(A) A := A - 50 write(A) read(A) temp = A *.1 A := A - temp write(A) read(B) B := B + 50 write(B) read(B) B := B + temp write(B)

12. Bad schedule T1T2 read(A) A := A - 50 read(A) temp = A *.1 A := A - temp write(A) read(B) write(A) read(B) B := B + 50 write(B) B := B + temp write(B)

13. Conflict Serializability Let instructions I and J belonging to transactions T1 and T2 be executed consecutively by the DBMS. 1.I and J can be swapped in their execution order if I and J refer to different data elements 2.I and J can be swapped in their execution order if I and J refer to the same data element and both perform a read operation only. 3.I and J are said to conflict if I and J belong to different transactions and at least one of them is a write operation

14. Conflict Serializability If a schedule S can be transformed to another S’ by swapping non conflicting instructions, then S and S’ are said to be conflict equivalent. A schedule S is said to be conflict serializable if it is conflict equivalent to some serial schedule. Ii=Read(Q), Ij=Read(Q) Ii=Read(Q),Ii=Write(Q)

15. Rules to define conflict operation 1.If two transaction just read a data object then they do not conflict and the order is not important. 2.If two transaction either read or write completely separate data objects then they don’t conflict and the order is not important. 3.If one transaction writes a data object and another either reads or writes the same data objects then the order of execution is important. 4.Two actions on the same data object conflict if at least one of them is a write.

16. T1T2 Read A Write A Read A Read B Write A Write B Read B Write B

17. T1T2 Read A Write A Read B Write B T1T2 Read B Write B Read A Write A T1T2 X=x+5 X=x*2 Y=Y-100 Y=Y*5 T1T2 X=x+5 X=x*2 Y=Y-100 Y=Y*5

18. View Serializability If S is a schedule, then S’ is a view equivalent schedule if For each data item Q, if a transaction Ti reads the initial value of Q in S, then it should read the initial value in S’ also In schedule S, for each data item Q, if write(Q) of Tj precedes read(Q) of Ti, it should be the same in S’ The same transaction that performs the final write(Q) in S, should perform it in S’.

19. View Serializability A view equivalent schedule: T3: Read(Q) T4: Write(Q) T3: Write(Q) T5: Write(Q) T3T4T5 Read Q Write Q

20. View Serializability Every conflict serializable schedule is also view serializable; however some view serializable schedules are not conflict serializable Example in previous slide A schedule that is view serializable but not conflict serializable is characterized by blind writes.

21. Serializable Executions An interleaved execution of some transactions is correct if it produces the same result as some serial execution of the transactions. Such an execution is called serializable. A concurrency control scheme must prevent non- serializable execution from occurring. One possibility is locking.

22. Locks Data items can be accessed in a mutually exclusive manner. While one transaction accesses a data item, no other transaction should modify it. Locking ensures that a data item can be updated only if the transaction holds a lock on the data item. Two types of lock: – Shared locks-can read data item, but can’t write. – Exclusive locks-can performed both read and write operation.

23. Shared locks If a transaction holds a shared lock (S-lock) on an object, other transactions can also request S-locks. However, a transaction cannot acquire an exclusive lock on the object. If a transaction has the only shared lock on an object, it can be promoted to an exclusive lock.

24. Recoverability->Rollback Recoverable schedule A recoverable schedule is one where, for each pair of transactions Ti and Tj such that Tj reads a data item previously written by Ti, the commit operation of Ti appears before the commit operation of Tj. Most database system require that all schedules be recoverable. Cascadeless schedules A single transaction failure leads to a series of transaction rollbacks, is called cascading rollback.

25. Concurrency control manager (1)Request (2)Grant T1 T2 CCM lock-X(A) Grant(X,A) Read(A) A := A – 50 Write(B) Unlock(A) Lock-x(B) lock S(A) Grant(X,B) Read(B) Read(A) B:=B+50; Display(A) Grant(S,A) Write(B) unlock(A) Unlock(B)

26. Exclusive Locks If a transaction holds an exclusive lock (X-lock) on an object, no other transaction can acquire a lock on the object, or access it. To update a record R through some transaction T – T must obtain an X-lock on R – The X-lock must be retained until the end of T, either through COMMIT or ROLLBACK

27. Locking protocols T1 T2 lock-X(A) read(A) A := A - 50 write(A) unlock(A lock-X(A) read(A) temp = A *.1 A := A - temp write(A) unlock(A)

28. X-locks Block Bad Interleaving T1 T2 lock-X(A) read(A) A := A - 50 read(A) The read(A) of T2 cannot be executed because T1 has an X-lock on A.

29. Deadlocks In a database, a deadlock is a situation in which two or more transactions are waiting for one another to give up locks. X-locks may lead to deadlocks. This arises when two transactions are mutually excluded from accessing the next record required to computer their transaction.

30. Example of Deadlock T1 T2 lock-X(B) update B lock-X(A) update A request lock(A) wait for T2 to release lock on A request lock(B) waiting for T1 to release lock on B

31. Deadlocks Deadlocks can be overcome by: 1 ) Prevention 2) Detection and Recovery 1 ) Prevention  “This approach ensures that system will never enter in dead deadlock state”  A transaction must lock all the data items it needs before execution begins.  Data-item utilization may be slow.  Ordering  If a transaction requires access to two records, make sure that they are always accessed in the same order.  In our case, always access A before B.  May slow down operations considerably

32.  Two different deadlock prevention schemes using timestamp are: 1.Wait die -The wait-die scheme is nonpreemption technique. 2.Wound wait -The wait-die scheme is preemptive technique.  Timeout based schemes In this approach, a transaction that has requested a lock waits for at most a specified amount of time.

33. Detection and Recovery “This approach tries to recover from deadlock if system enters in deadlock state” Periodically, let DBMS check to determine if line waiting for resource exceeds some limit. Use graph manipulation to detect deadlocks: – Draw arrow from transaction to record being sought, and from record to transaction using it. – If graph has cycles, then we have deadlock. If deadlock detected, cancel one transaction and advance other.