Consistency in distributed systems Distributed systems Lecture # 10 Distributed systems Lecture # 10

Overview  Transactions  ACID  Concurrency  Locking  Timestamping  Optimistic concurrency control  Transactions  ACID  Concurrency  Locking  Timestamping  Optimistic concurrency control

transactions  Distributed systems is essentially about understanding when to use and when not to use transactions  Examples of transaction-based systems  Banking systems  Airline Ticketing systems  system?  Web cache coherence?  Distributed systems is essentially about understanding when to use and when not to use transactions  Examples of transaction-based systems  Banking systems  Airline Ticketing systems  system?  Web cache coherence?

ACID transactions  Problem  Update state on several distributed hosts  Conditions  Atomic  Consistent  Isolation  Durable  Problem  Update state on several distributed hosts  Conditions  Atomic  Consistent  Isolation  Durable

In simple words  Either do all x steps or don’t do anything  A transaction must not be affected by other ongoing transactions  Before and after the transaction everyone should be consistent  Your changes must remain consistent once you are done  Either do all x steps or don’t do anything  A transaction must not be affected by other ongoing transactions  Before and after the transaction everyone should be consistent  Your changes must remain consistent once you are done

Subtle issues  Transactions implicitly give you an “undo” button  Recoverable from failures  Transactions serialize operations, without compromising concurrency  As much as a function of transactional model as good software engineering  Transactions implicitly give you an “undo” button  Recoverable from failures  Transactions serialize operations, without compromising concurrency  As much as a function of transactional model as good software engineering

A Simple transaction  mybankAccount.withdraw(1000) if (mybankAccount.balance > 5000) mybankAccount.withdraw (3000) else myWifebankAccount.transfer(mybankAc count, (5000))  mybankAccount.withdraw(1000) if (mybankAccount.balance > 5000) mybankAccount.withdraw (3000) else myWifebankAccount.transfer(mybankAc count, (5000))

Distributed transaction Source Server C Server B Server A Open Transaction

Distributed transaction Source Server C Server B Server A Withdraw Money Deposit Money

Distributed transaction Source Server C Server B Server A Close Transaction

Under the hood  Requests are serialized  Changes saved in durable storage  Multiple transactions can run concurrently  Requests are serialized  Changes saved in durable storage  Multiple transactions can run concurrently

Commit protocol  Voting phase  Preparation of commitment  Everyone answers yes  Then commit  Two Phase Commit  Voting phase  Preparation of commitment  Everyone answers yes  Then commit  Two Phase Commit

2 Phase Commit ClientServer Can commit? yes Do Commit Committed

Failure model?  Any NACK, Time-out, causes Abort  Server Crash?  Client Crash?  Coordinator based model?  Coordinator crash?  Any NACK, Time-out, causes Abort  Server Crash?  Client Crash?  Coordinator based model?  Coordinator crash?

Concurrency in transactions  Nested transactions  Child transactions run in tandem  Parallel (different hosts)  Concurrent (different data)  Parent can commit even if a child aborts  However  If the parent aborts, should a child abort?  Nested transactions  Child transactions run in tandem  Parallel (different hosts)  Concurrent (different data)  Parent can commit even if a child aborts  However  If the parent aborts, should a child abort?

Nested Transactions

Deep nesting  Provisional commit  Level 3 “can” commit  Level 2 can only provisionally commit  Can end up with orphan transactions  Provisional commit  Level 3 “can” commit  Level 2 can only provisionally commit  Can end up with orphan transactions

concurrency  Lamport timestamps  Typically NTP time  Nest lecture  Optimistic concurrency control  Lamport timestamps  Typically NTP time  Nest lecture  Optimistic concurrency control