Atomic Actions

1. Atomic Actions

2. Atomic actions • Recovery at the application level is simpler to program if the computation is a sequence of sub-computations and each of these is • Either executed in full • Or completely fails to execute An action that either completes or has no effects at all is called “Atomic action” Concept of transaction and ACID properties of transactions

3. Transactions in databases • Transaction: a sequence of changes to a data collection that move it from a consistent state to another consistent state. • A transactionis a unit of program execution that accesses and possibly updates various data items.(originates in transaction processing application: banking, ….) • Purposes of atomic transactions:make information states of data invisible to other clients for concurrency control and fault tolerance.

4. Transactions in databases Concept of transaction and ACID properties of transactions: Atomicity(or recoverability) “all or nothing property with respect to failures” Consistencyeach transaction preserves required invariants over the data Isolation (concurrency atomicity)concurrent transaction have the same effect as though they were sequential Durability(or permanence)once a transaction is committed, failures cannot desroy its effects

5. Transactions in databases • Let T1 and T2 be atomic transactions. Transaction T1 Transaction T2 • An erroneous state before the termination of the transaction, results into a rollback of the transaction • An erroneous state after the termination of the transaction must have no consequences

6. Transactions in databases • A transactionis a unit of program execution that accesses and possibly updates various data items. • E.g. transaction to transfer 50 Euro from account A to account B: • 1. read(A) • 2. A := A – 50 • 3. write(A) • 4. read(B) • 5. B := B + 50 • write(B) • Two main issues to deal with: • Failures of various kinds, such as hardware failures and system crashes • Concurrent execution of multiple transactions

7. Transactions in databases • Transaction to transfer 50 from account A to account B: • 1. read(A) • 2. A := A – 50 • 3. write(A) • 4. read(B) • 5. B := B + 50 • write(B) • Atomicity requirement • if the transaction fails after step 3 and before step 6, money will be “lost” leading to an inconsistent database state (Failure could be due to software or hardware) • the system should ensure that updates of a partially executed transaction are not reflected in the database • Durability requirement — once the user has been notified that the transaction has completed (i.e., the transfer of the 50 Euro has taken place), the updates to the database by the transaction must persist even if there are software or hardware failures.

8. buffer input(A) Buffer Block A X A Buffer Block B Y B output(B) read(X) write(Y) x2 x1 y1 work area of T2 work area of T1 disk memory Modified buffer blocks in main memory reported onto disk following different approaches: 1) Deferred database modification 2) Immediate database modification 3) Mixed approach

9. Transaction State Active –the initial state; the transaction stays in this state while it is executing Partially committed –after the final statement has been executed. Failed -- after the discovery that normal execution can no longer proceed. Aborted – after the transaction has been rolled back and the database restored to its state prior to the start of the transaction. Two options after it has been aborted: restart the transaction kill the transaction Committed – after successful completion.

10. Log-based recovery mechanisms • A Log is kept on stable storage. • The log is a sequence of log records, and maintains a record of update activities on the database. • When transaction Tistarts, it registers itself by writing a BEGIN log record (B(Ti)) • Before Tiexecutes insert, delete or update of a record, a log record is written • D (O1, BS1)where O1 is the object deleted and BS1 (Before State) is the value of O1 • I (O1, AS1) • where O1 is the object inserted and AS1 (After State) is the value of O1 • U (O1, BS1, AS1) • where O1 is the object updated, BS1is the value of O1 before the update (the old value) and AS1is the value of O1 after the update (the new value). • When Ti finishes its last statement, the log record COMMIT is written (C(Ti)). • If Ti aborts the log record ABORT is written (A(Ti))

11. Checkpointing • The system periodically performs checkpointing - Output all modified buffer blocks of committed transactions to the disk. - Write a log record CHECKPOINT( L) onto stable storage where L is a list of all transactions active at the time of checkpoint (CK(L)). • - All updates are stopped while doing checkpointing • Special log record DUMP correponds to a complete backup of the database.

12. Log structure Crash CK(T1,T2) CK(T1,T3) B(T1) B(T2) C(T2) B(T3) dump U(T2,…) U(T2,…) U(T1,…) U(T1,…) U(T3,…) U(T3,…) Da: Atzeni, Ceri, Paraboschi, Torlone - Basi di Dati: Architetture e linee di evoluzione

13. Recovery Algorithm • Transaction rollback (during normal operation) • Let Ti be the transaction to be rolled back • Scan log backwards from the end, and for each log record of Ti • perform the undo of the operation and write the corresponding log record ( such log records are called compensation log records) • Once the record B(Ti) is found stop the scan and write the log record A(Ti)

14. Recovery Algorithm • Recovery from failure: • Find last checkpoint record CK(L). • Create the REDO and UNDO sets.REDO contains the transactions whose operations must be redone. UNDO contains the transactions whose operations must be undone. • Set REDO = {} UNDO = {L} • Scan forward the Log starting from the checkpoint. - For each B(Tj) add Tj to UNDO - For each C(Tj) move Tj from UNDO to REDO • 3.Undo Phase • Scan backward the Log and undo the operations of transactions in UNDO • 4. Redo Phase • Scan forward the Log and redo the operations of transaction in REDO

15. T1 Example B(T1) B(T2) U(T2, O1, B1, A1) I(T1, O2, A2) B(T3) C(T1) B(T4) U(T3,O2,B3,A3) U(T4,O3,B4,A4) CK(T2,T3,T4) C(T4) B(T5) U(T3,O3,B5,A5) U(T5,O4,B6,A6) D(T3,O5,B7) A(T3) C(T5) I(t2,O6,A8) Crash CK C T2 T3 A T4 C T5 Da: Atzeni, Ceri, Paraboschi, Torlone - Basi di Dati: Architetture e linee di evoluzione

16. T1 1. Find last checkpoint B(T1) B(T2) U(T2, O1, B1, A1) I(T1, O2, A2) B(T3) C(T1) B(T4) U(T3,O2,B3,A3) U(T4,O3,B4,A4) CK(T2,T3,T4) C(T4) B(T5) U(T3,O3,B5,A5) U(T5,O4,B6,A6) D(T3,O5,B7) A(T3) C(T5) I(t2,O6,A8) CK = {T2,T3,T4} Crash CK C T2 T3 A T4 C T5 Da: Atzeni, Ceri, Paraboschi, Torlone - Basi di Dati: Architetture e linee di evoluzione

17. 2. Build the sets UNDO and REDO B(T1) B(T2) 8. U(T2, O1, B1, A1) I(T1, O2, A2) B(T3) C(T1) B(T4) 7. U(T3,O2,B3,A3) 9. U(T4,O3,B4,A4) CK(T2,T3,T4) 1. C(T4) 2. B(T5) 6. U(T3,O3,B5,A5) 10. U(T5,O4,B6,A6) 5. D(T3,O5,B7) A(T3) 3. C(T5) 4. I(T2,O6,A8) 0. UNDO = {T2,T3,T4}. REDO = {} 1. C(T4)  UNDO = {T2, T3}. REDO = {T4} 2. B(T5)  UNDO = {T2,T3,T5}. REDO = {T4} 3. C(T5)  UNDO = {T2,T3}. REDO = {T4, T5} Da: Atzeni, Ceri, Paraboschi, Torlone - Basi di Dati: Architetture e linee di evoluzione

18. 3. Undo Phase B(T1) B(T2) 8. U(T2, O1, B1, A1) I(T1, O2, A2) B(T3) C(T1) B(T4) 7. U(T3,O2,B3,A3) 9. U(T4,O3,B4,A4) CK(T2,T3,T4) 1. C(T4) 2. B(T5) 6. U(T3,O3,B5,A5) 10. U(T5,O4,B6,A6) 5. D(T3,O5,B7) A(T3) 3. C(T5) 4. I(T2,O6,A8) 0. UNDO = {T2,T3,T4}. REDO = {} 1. C(T4)  UNDO = {T2, T3}. REDO = {T4} 2. B(T5)  UNDO = {T2,T3,T5}. REDO = {T4} 3. C(T5)  UNDO = {T2,T3}. REDO = {T4, T5} 4. D(O6) 5. O5 =B7 6. O3 = B5 7. O2 =B3 8. O1=B1 Undo Da: Atzeni, Ceri, Paraboschi, Torlone - Basi di Dati: Architetture e linee di evoluzione

19. 4. Redo Phase B(T1) B(T2) 8. U(T2, O1, B1, A1) I(T1, O2, A2) B(T3) C(T1) B(T4) 7. U(T3,O2,B3,A3) 9. U(T4,O3,B4,A4) CK(T2,T3,T4) 1. C(T4) 2. B(T5) 6. U(T3,O3,B5,A5) 10. U(T5,O4,B6,A6) 5. D(T3,O5,B7) A(T3) 3. C(T5) 4. I(T2,O6,A8) 0. UNDO = {T2,T3,T4}. REDO = {} 1. C(T4)  UNDO = {T2, T3}. REDO = {T4} 2. B(T5)  UNDO = {T2,T3,T5}. REDO = {T4} 3. C(T5)  UNDO = {T2,T3}. REDO = {T4, T5} 4. D(O6) 5. O5 =B7 6. O3 = B5 7. O2 =B3 8. O1=B1 9. O3 = A4 10. O4 = A6 Setup Undo Redo Da: Atzeni, Ceri, Paraboschi, Torlone - Basi di Dati: Architetture e linee di evoluzione

20. Atomicity: a transaction either completes or has no effects • Atomicity of a transaction: • Log in stable storage + checkpointing + recovery algorithm A programmer assumes atomicity of transactions

21. Distributed transactions Assume a distributed database of a bank An example of distributed transaction is: add 1000 Euro to all accounts 1 2 4 3 node1 node4 BEGIN TRANSACTION UPDATE accont SET account = account + 1000 COMMIT END TRANSACTION node2 node3 Da: Atzeni, Ceri, Paraboschi, Torlone - Basi di Dati: Architetture e linee di evoluzione

22. Global decision Complete Prepare TM Local decision Prepare msg Decision msg Ack msg Ready Ready msg RM Atomicity (distributed transactions) • - One transaction manager TM • - Many resource managers RM • Log file (persistent memory) • time-out Two-phase commit protocol Tolerates: loss of messages crash of nodes

23. Protocollo con time-out e finestra di incertezza Da: Atzeni, Ceri, Paraboschi, Torlone - Basi di Dati: Architetture e linee di evoluzione Uncertain period: if the transaction manager crash, a participant with Ready in its log cannot terminate the transaction

24. A complete transaction Da: Atzeni, Ceri, Paraboschi, Torlone - Basi di Dati: Architetture e linee di evoluzione

25. Four-phase commit Da: Atzeni, Ceri, Paraboschi, Torlone - Basi di Dati: Architetture e linee di evoluzione

26. Three-phase commit Da: Atzeni, Ceri, Paraboschi, Torlone - Basi di Dati: Architetture e linee di evoluzione

27. TM crash • If the TM crashes and does not recover, any participant can assume the role of transaction manager and correctly terminate the transaction • The participant, scan the Log backward: • Last record in the Log for the transaction: • - Ready • abort the transaction • - Pre-commit • commit the transaction

28. Atomic transactions • Structuring principles: • -Checkpointing • - Atomicity Advantages of atomic transactions: a designer can reason about system design as1) no failure happened in the middle of a transaction 2) operations from separate transactions were never interleaved (property called “serializability”). Concurrency control : - strict two phase locking - time-stamp

29. Atomic actions • Limiting the extent of error propagation when faults occur and localizing the subsequent error recovery are common concerns in the design of fault tolerant parallel processing systems. • Both activities are made easier if the designer associates fault tolerance mechanisms with the underlying atomic actions of the system. • The Coordinated Atomic Action concept was introduced in 1995 for modeling complex fault-tolerant object-oriented concurrent systems, defined as a collection of interacting Objects • Rigorous development of an embedded fault-tolerant system based on coordinated atomic actions • J. Xu, B. Randell, A. Romanovsky, R.J. Stroud, A.F. Zorzo,E. Canver, F. von Henke. Rigorous Development of a Safety-Critical System Based on Coordinated Atomic Actions. In FTCS-29, Madison, USA, pp. 68-75, 1999.