Atomic Actions

1. Atomic Actions CprE 545: Fault-Tolerant Systems (prepared by G. Sudha Anil Kumar) Iowa State University

2. Atomic Actions • Indivisibility • Non-interference • Strict sequencing • All or nothing

3. ACID Properties of Transactions • Atomicity: either all or none of the effects of the transaction are made permanent. • Consistency: the effect of concurrent transactions is equivalent to some serial execution. • Isolation: transactions cannot observe each other’s partial effects. • Durability: once committed, the effects of a transaction are permanent regardless of failures.

4. Transactions – An Example • Transfer $500 from A to B • Begin Transaction • Read account A • Read account B • Add $500 to B • Subtract $500 from A • Write new value of A back to database • Write new value of B back to database • Commit both writes • End Transaction

5. Schedule and Serial Schedule • Consider “m” concurrent transactions T1, T2, T3…Tm. Any sequence of operations obtained by collating the operations of the different transactions is called a schedule. • In a schedule, the order of operations of a transaction is maintained, but operations of different transactions can interleave in any manner. • A schedule is called a serial schedule if all the operations of a transaction occur together (i.e. contiguously) in the schedule. • A serial schedule represents a serial execution of the transactions in which the execution of a new transaction is initiated only when the execution of the previous transaction is completed • A serial schedule will never lead to inconsistency, as a new transaction starts only after the previous one has completed fully.

6. Example • Transaction T1 = (read A, write A, read B, write B); • Transaction T2 = (read B, write B, read A, write A); An example Schedule A Serial Schedule

7. Serializability • Non-serial schedules have the potential to lead the collection of data entities to an inconsistent state, but they also permit concurrent access to shared data. • Since the transactions are to be executed atomically, the internal state of a transaction should not be visible to any other transaction, and a transaction should appear as a primitive, indivisible action to others. • No two transactions should appear as a primitive, indivisible action that the net result of executing different transactions should be as if the transactions were executed serially in some order. This is called the serializability criteria. • Serializability means that the schedule of transactions should be such that it is equivalent to some serial schedule.

8. Serializability Test: The Dependency Graph • A dependency graph can be constructed for every schedule with transactions as the set of nodes. • The edges are drawn as per the following rules: • Draw an edge from Ti to Tk if Ti reads an entity which is later written by Tk (READ-WRITE conflict) • Draw an edge from Ti to Tk if Ti writes an entity which is later written by Tk (WRITE-WRITE conflict) • Draw an edge from Ti to Tk if Ti writes an entity which is later read by Tk (WRITE-READ conflict) • The dependency graph is acyclic if the schedule is serializable. This condition is sufficient for a schedule to be serializable. Otherwise, the schedule is non-serializable.

9. Serializability Test: Example • T1 = (read A, write A, read B, write B); • T2 = (read B, write B, read A, write A); B A T1 T2 B Hence, the schedule is non serializable!!

10. Concurrency Control • How to control access by concurrent transactions to shared data such that atomicity is not violated because of concurrency ? • Objective: To execute concurrent transactions in such a manner that their final schedule is serializable. • Clearly, some restrictions on transactions and their interactions will have to be imposed so that the serializability criterion is satisfied. Protocols that impose such restrictions are called concurrency control protocols. • The problem of concurrent access is present in both the databases and operating systems.

11. Concurrency Control • In the context of operating systems, the concurrency problem is solved by requiring that critical, shared data be accessed by different processes in a mutually exclusive manner. Using semaphores is one of the solutions. • In OS, the shared data is typically small and accesses are needed to these data infrequently and for a very short duration. • In the context of databases, where the shared data may be large, and actions that need to be executed atomically may not be small or infrequent, this approach is too restrictive.

12. Two-Phase Locking • Two-phase locking allows limited concurrent access to shared data, without violating the serializaibility requirement. Many commercial databases use two-phase locking for concurrency control. Protocol: • Two-phase locking protocol employs the locking of entries for access control. • A transaction can lock an entity by requesting a lock on the entity (or performing a lock() operation), and can release the lock on an entity by an unlock() operation. • A lock may be granted to a transaction immediately or the transaction may be delayed until the lock is available. • Locks can be read locks or write locks. • Multiple transactions can concurrently hold read locks on an entity, but a write lock is exclusive.

13. Two-Phase Locking • Two-phase locking imposes the following restrictions on each transaction: • A transaction T can read/write on an entity “e” if and only if, T possesses a read/write lock on “e”. • A transaction cannot request a lock after releasing any lock. • Two-phase locking divides the transaction into two phases: • In the first phase (growing phase), the transaction requests locks on entities. • Once it releases the first lock, it enters the second phase (the shrinking phase), since after this phase it cannot request any further locks and can only release locks. • Two-phase locking (2PL) always produces a serializable schedule.

14. Two Phase Locking: Example • T1 = (read A, write A, read B, write B); • T2 = (read B, write B, read A, write A); • T3 = (read C, write C)

15. Two-Phase Locking: Problems • 2PL can result in deadlock. • Example: • Both Ti and Tj need to lock on both x and y • Ti locks x • Tj locks y • Ti tries to lock y and gets blocked • Tj tries to lock x and gets blocked • No one proceeds, hence deadlock.

16. Dealing with Deadlocks • Deadlock: Cycle of transactions waiting for locks to be released by each other. • Two ways of dealing with deadlocks: • Deadlock prevention • Deadlock detection

17. Deadlock Detection • Approach 1: Timeout Mechanism. • One waits too long is in deadlock. (Not good) • Approach 2: Create a waits-for graph: • Nodes are transactions • There is an edge from Ti to Tj if Ti is waiting for Tj to release a lock • Periodically check for cycles in the waits-for graph

18. Deadlock Detection (Contd.) Example: T1: S(A), R(A), S(B) T2: X(B),W(B) X(C) T3: S(C), R(C) X(A) T4: X(B) T1 T2 T1 T2 T4 T3 T3 T3

19. Deadlock Detection (Continued) • Resolve deadlock: • aborting a transaction that is on a cycle. Releasing its locks. • Which transaction to abort? • One with fewest locks. • One has done least work. • One that is farthest from completion.

20. Deadlock Prevention • Why deadlock prevention? • Detecting based schemes work well when deadlocks are infrequent. • When high likelihood of deadlocks: preventing based schemes. • How to prevent? • Assign priorities based on timestamps. The lower the timestamp, the higher the transaction's priority. • Two policies are possible (Assume Ti wants a lock that Tj holds): • Wait-Die: If Ti has higher priority, Ti waits for Tj; otherwise Ti aborts (Lower priority never wait for higher priority) • Wound-wait: If Ti has higher priority, Tj aborts; otherwise Ti waits (Higher priority never waits for lower priority)

21. Deadlock Prevention • Starving transaction? • Transaction is permaentally aborted because it never has a sufficient high priority? • Solution: If a transaction restarts, make sure it has its original timestamp. • Each transaction will eventually become the oldest transaction, and get highest priority.

22. Handle Site/Node Failures • Write ahead log (WAL) protocol • Before overwriting an object in the stable storage with uncommitted updates, a transaction should first write its undo log for this update. • Before committing an update to an object in the stable storage, the transaction must write the redo log.

23. Example… • Similar to the bank transfer example, here is the sequence of action that person A withdraws $500 from an ATM machine: • Begin Transaction • Read account A • If A has enough money • dispense $500 dollars cash • Subtract $500 from account A • Write new value of A back to database • Commit the write • End transaction • What happens when database is distributed and failures occur, and how to fix the problems?

24. Challenge: • What happen if database for A and database for B are not in the same location or if database A has replication? • Commit protocols

25. Commit protocols for Distributed Systems • The data is distributed over many nodes. Each node manages some data entities, and only that node can access the data. • A process (transaction) that wants to perform an operation on an entity must request the node managing that entity to actually perform that operation. • Hence, different operations of a transaction may be performed on different nodes. • Unlike a centralized system, where a failure means complete failure, in a distributed system, a failure of a node does not stop all computation of a transaction. • Only those parts of the transaction that are to be performed at the failed node are affected, the other actions remain unaffected. • This complicates the activity of committing a transaction. Since a transaction is “all-or-nothing” operation, if some part of the transaction cannot be done, then all the activities of the transaction must be undone to give the effect that nothing was done by the transaction.

26. Commit protocols for Distributed Systems • Goal • To ensure that either all the nodes taking part in the transaction commit the transaction, or all of them abort. • Assumptions • One of the cooperating processes acts as a coordinator • Coordinator cooperate with other processes called cohorts • Stable storage is available at each site • At the beginning of a transaction the coordinator sends a start transaction message to every cohort

27. Two-Phase Commit ProtocolFinite state Automate (FSA) Cohort i Coordinate 1. Commit_Request message received qi q1 1.Commit_Request message received 1. Commit_request message sent to all cohorts 2.Abort message sent to coordinator 2.Agreed message sent to coordinator 2. One or more cohort(s) replied abort 2. All cohorts agreed 3. Send commit w1 wi ai 3. Abort message sent to all cohorts message 3. Abort message received from coordinator To call cohorts 3.Commit message received from coordinator c1 a1 ci

28. Two Phase Commit Protocol Phase 1 • Coordinator • sends a Commit_Request message to every cohort waits for replies from all the cohorts • Cohorts • On receiving Commit_request message if the transaction execution is successful the cohort writes undo and redo log on the stable storage, sends an Agreed message to the coordinator; otherwise sends an Abort message to the coordinator.

29. Two Phase Commit Protocol(cont.) Phase 2 • Coordinator • if all cohorts reply Agreed and the coordinator also agrees, the coordinator • writes Commit into the log • sends Commit to all the cohorts • otherwise sends an Abort message to all the cohorts • waits for Acknowledgments from each cohort • If an Acknowledgment did not arrive from any cohort within a timeout (phase 1), the coordinator resends the Commit/Abort message to that cohort • If all acknowledgments are received, the coordinator writes a Complete record to the log (ends the transaction).

30. Two Phase Commit Protocol(cont.) • Cohorts (Phase 2) • On receiving a Commit message, a cohort • release the resources and locks used for executing the transaction, complete the transaction, sends an acknowledgment. • On receiving an Abort, a cohort • undo the transaction using the undo log record, release all the resources and locks held to, complete the transaction, sends an acknowledgment

31. Observations • If the absence of failures, the 2PC protocol ensures atomicity. However, the protocol is very vulnerable to failures. • At many stages processes (participants or the coordinator) are waiting for some messages to arrive. If the messages do not arrive due to network failure or sender failure, the process will remain blocked.

32. Where Could 2PCP Block? Cohort i Coordinate Commit_Request message received qi q1 Commit_Request message received Commit_request message sent to all cohorts Abort message sent to coordinator Agreed message sent to coordinator One or more cohort(s) replied abort All cohorts agreed Send commit w1 wi ai Abort message sent to all cohorts message Abort message received from coordinator To call cohort Commit message received from coordinator c1 a1 ci

33. Site/Node Failures • Coordinator crashes before having written the Commit message • on recovery the coordinator broadcast an Abort message to all cohorts • all cohorts who agreed to commit undo the transaction using undoing log • Others Abort the transaction • Coordinator crashes after writing Commit but before Complete record. • On recovery the Coordinator broadcasts Commit message to all cohorts and waits for Acknowledgment. • Coordinator crashes after writing Complete message • on recovery there is nothing to be done for the transaction

34. Site/Node Failures (cont.) • A cohort crashes in phase1 • the coordinator can abort the transaction as it did not receive reply from the crashed cohort • A cohort crashes in phase 2 (after writing Undo and Redo logs) • on recovery, the cohort checks with the coordinator what to do - Abort or Commit • Redo might be required if the cohort failed before updating the database

35. Nonblocking Commit protocol • Need a commit protocol that: • is nonblocking • tolerates site failures • Assumptions • the network is reliable • the point-to-point communication is possible between any two operational nodes • the network can detect node failures (e.g.,by a timeout) and report it to the site trying to communicate with the failed site

36. Nonblocking Protocols • A protocol that never requires an operational site to block even if other sites is called a nonblocking protocol. • In a nonblocking protocol, the sites that are operational can always reach a decision about the whether they should commit or not. • It is important to note that, if the communication network fails then there can be no nonblocking protocol. • Therefore, all nonblocking protocols assume a reliable network and only site failures are considered.

37. Definitions • Concurrency Set of a state of an FSA • For a given state, s, at one site, the concurrent set C(s) of the site is the set of all states in which all other sites can be. • For example, in a system with coordinator 1, cohort 2 and cohort 3, C(w1) of the coordinator is {q3, w3, a3, q2, w2, a2}. • Committable state • A state of an FSA is committable if occupancy of that state by the site means that all sites have voted YES on committing the transaction. • Blocking • When a site has a concurrent set which contains both commit and abort states or • Whenever the site is in a noncommittable state and the concurrency set for that state contains a commit state. • For example, consider the above example, C(w2) of the cohort 2 is {w1, a1, c1, q3, w3, a3, c3}.

38. Nonblocking Protocol • A protocol is nonblocking if and only if, it satisfies both these conditions for every state in every participating site FSA: • There exists no local state such that its concurrency set contains both an abort and a commit state. • There exists no noncommittable state whose concurrency set contains a commit state.

39. How to Eliminate Blocking in 2PC ? • If a protocol contains local state of a site with both Abort and Commit states in its concurrency set, then under independent recovery conditions it is not resilient to an arbitrary single failure • In the finite state automaton representation of the 2PCP, only states wi(i1) have both Abort and Commit states in their concurrency sets • Sufficient to ensure that C(wi) does not contain both Abort and Commit states • Can be achieved by introducing a buffer state pi in the finite state automaton representing 2PCP • e.g.,a system contain only two sites • C(w1)={q2,a2,w2} and C(w2)={a1,p1,w1)

40. How to Eliminate Blocking in 2PC ? • In terms of phases, the introduction of the buffer state adds another phase in the protocol, and the 2PC becomes a three-phase commit (3PC) protocol. The buffer state can be treated as a prepare to commit state. • In 3PC, after the coordinator gets YES votes from all the participants, instead of committing, it sends a “prepare to commit” message to all participants, and moves to its state “p”. • On receiving the “prepare to commit” message, each participant sends an ack and moves to its own prepare state “p”. • Finally, when the coordinator receives acks from all the participants, it sends a commit message to all participants.

41. More on 3PC protocol • Once a process has reached its ”prepare to commit” state, it knows that it will commit eventually. • And before this state, it has the option of unilaterally aborting the transaction. • Since once a process reaches state “p”, it always commits, the state seems redundant. Indeed, it is not of any real use in a failure-free situation. • However, if failures occur, the existence of this state makes this protocol nonblocking.

42. 3PCP Coordinator Cohort i q1 qi Commit_Request message sent to all cohorts wi ai {q,w,p} w1 Abort message received from coordinator a1 p1 pi Commit message received from coordinator c1 ci