D ISTRIBUTED S YSTEMS [COMP9243] Defines a sequence of operations - PowerPoint PPT Presentation

T RANSACTIONS Transaction: ➜ Comes from database world D ISTRIBUTED S YSTEMS [COMP9243] ➜ Defines a sequence of operations ➜ Atomic in presence of multiple clients and failures Lecture 5: Synchronisation and Coordination Mutual Exclusion ++: ➜ Protect shared data against simultaneous access (Part 2) Slide 1 Slide 3 ➜ Allow multiple data items to be modified in single atomic action Transaction Model: ➀ Transactions ➁ Elections Operations: End of Transaction: ➂ Multicast ➜ BeginTransaction ➜ Commit ➜ EndTransaction ➜ Abort ➜ Read ➜ Write T RANSACTION E XAMPLES Inventory: Previous inventory New inventory Input tapes Computer Output tape Today's T RANSACTIONS updates Slide 2 Slide 4 Banking: BeginTransaction b = A.Balance(); A.Withdraw(b); B.Deposit(b); EndTransaction T RANSACTIONS 1 ACID P ROPERTIES 2

ACID P ROPERTIES N ESTED T RANSACTION atomic: all-or-nothing. once committed the full transaction is Example: performed, if aborted, there is no trace left; Booking a flight consistent: the transaction does not violate system invariants � Sydney → Manila (i.e. it does not produce inconsistent results) � Manila → Amsterdam Slide 5 Slide 7 � Amsterdam → Toronto isolated: transactions do not interfere with each other i.e. no intermediate state of a transaction is visible outside What to do? (also called serialisable); ➜ Abort whole transaction ➜ Commit nonaborted parts of transaction only durable: after a commit, results are permanent (even if ➜ Partially commit transaction and try alternative for aborted part server or hardware fails) C LASSIFICATION OF T RANSACTIONS T 11 abort Flat: sequence of operations that satisfies ACID T 1 commit Nested: hierarchy of transactions T 12 commit commit Distributed: (flat) transaction that is executed on distributed T data T 21 abort Slide 6 Slide 8 Flat Transactions: T 2 abort � Simple T 22 abort BeginTransaction � Failure → all changes un- accountA -= 100; ➜ Subtransactions and parent transactions done accountB += 50; ➜ Parent transaction may commit even if some subtransactions aborted accountC += 25; accountD += 25; ➜ Parent transaction aborts → all subtransactions abort EndTransaction N ESTED T RANSACTION 3 N ESTED T RANSACTION 4

Writeahead Log: ➜ In-place update with writeahead logging Subtransactions: ➜ Roll back on Abort ➜ Subtransaction can abort any time ➜ Subtransaction cannot commit until parent ready to commit • Subtransaction either aborts or commits provisionally Slide 9 Slide 11 • Provisionally committed subtransaction reports provisional commit list, containing all its provisionally committed subtransactions, to parent • On commit, all subtransaction in that list are committed • On abort, all subtransactions in that list are aborted. T RANSACTION A TOMICITY I MPLEMENTATION C ONCURRENCY C ONTROL (I SOLATION ) Private Workspace: Simultaneous Transactions: ➜ Perform all tentative operations on a shadow copy ➜ Clients accessing bank accounts ➜ Atomically swap with main copy on Commit ➜ Travel agents booking flights ➜ Discard shadow on Abort . ➜ Inventory system updated by cash registers Problems: Private ➜ Simultaneous transactions may interfere workspace Original index Slide 10 Index Slide 12 0 0 • Lost update 0 0 1 1 1 1 2 2 • Inconsistent retrieval 2 2 3 3 ➜ Consistency and Isolation require that there is no interference Why? 0 0 1 2 1 2 1 2 Concurrency Control Algorithms: 0 3 0 3 ➜ Guarantee that multiple transactions can be executed Free blocks simultaneously while still being isolated. (a) (b) (c) ➜ As though transactions executed one after another T RANSACTION A TOMICITY I MPLEMENTATION 5 C ONFLICTS AND S ERIALISABILITY 6

C ONFLICTS AND S ERIALISABILITY S ERIALISABLE E XECUTION Read/Write Conflicts Revisited: Serial Equivalence: ➜ conflicting operations performed in same order on all data conflict: operations (from the same, or different transactions) items that operate on same data • operation in T 1 before T 2 , or read-write conflict: one of the operations is a write Slide 13 Slide 15 • operation in T 2 before T 1 write-write conflict: more than one operation is a write Are the following serially equivalent? ➜ R 1 ( x ) W 1 ( x ) R 2 ( y ) W 2 ( y ) R 2 ( x ) W 1 ( y ) Schedule: ➜ R 1 ( x ) R 2 ( y ) W 2 ( y ) R 2 ( x ) W 1 ( x ) W 1 ( y ) ➜ Total ordering (interleaving) of operations ➜ R 1 ( x ) R 2 ( x ) W 1 ( x ) W 2 ( y ) R 2 ( y ) W 1 ( y ) ➜ Legal schedules provide results as though transactions serialised ➜ R 1 ( x ) W 1 ( x ) R 2 ( x ) W 2 ( y ) R 2 ( y ) W 1 ( y ) ( serial equivalence ) Example Schedules: M ANAGING C ONCURRENCY Dealing with Concurrency: Slide 14 Slide 16 ➜ Locking ➜ Timestamp Ordering ➜ Optimistic Control S ERIALISABLE E XECUTION 7 M ANAGING C ONCURRENCY 8

T WO P HASE L OCKING (2PL) Transaction Managers: Lock point Number of locks Transactions Growing phase Shrinking phase READ/WRITE BEGIN_TRANSACTION Transaction END_TRANSACTION manager Slide 17 Slide 19 LOCK/RELEASE Time or Scheduler Timestamp operations ➀ Lock granted if no conflicting locks on that data item. Data Execute read/write manager Otherwise operation delayed until lock released. ➁ Lock is not released until operation executed by data manager ➂ No more locks granted after a release has taken place All schedules formed using 2PL are serialisable. P ROBLEMS WITH L OCKING Deadlock: ➜ Detect and break deadlocks (in scheduler) L OCKING ➜ Timeout on locks Pessimistic approach: prevent illegal schedules Cascaded Aborts: Slide 18 Slide 20 ➜ Lock must be obtained from scheduler before a read or write. ➜ Release ( T i , x ) → Lock ( T j , x ) → Abort ( T i ) ➜ Scheduler grants and releases locks ➜ T j will have to be aborted too ➜ Ensures that only valid schedules result ➜ Problem: dirty read: seen value from non-committed transaction solution: Strict Two-Phase Locking: ➜ Release all locks at Commit / Abort T WO P HASE L OCKING (2PL) 9 T IMESTAMP O RDERING 10

T IMESTAMP O RDERING ➜ Each transaction has unique timestamp ( ts ( T i ) ) ➜ Each operation ( TS ( W ) , TS ( R ) ) receives its transaction’s timestamp O PTIMISTIC C ONTROL ➜ Each data item has two timestamps: • read timestamp: ts RD ( x ) - transaction that most recently Assume that no conflicts will occur. read x ➜ Detect conflicts at commit time • write timestamp: ts W R ( x ) - committed transaction that most Slide 21 Slide 23 ➜ Three phases: recently wrote x • Working (using shadow copies) ➜ Also tentative write timestamps (noncommitted writes) ts wr ( x ) • Validation ➜ Timestamp ordering rule: • Update • write request only valid if TS ( W ) > ts W R and TS ( W ) ≥ ts RD • read request only valid if TS ( R ) > ts W R ➜ Conflict resolution: • Operation with lower timestamp executed first Write Read ts RD (x) ts WR (x) ts(T ) ts RD (x) ts WR (x) ts(T ) 3 3 Validation: (T ) (T ) (T ) (T ) (T ) (T ) 2 2 3 2 2 3 ➜ Keep track of read set and write set during working phase ➜ During validation make sure conflicting operations with ts WR (x) ts (x) ts(T ) ts WR (x) ts (x) ts(T ) wr 3 wr 3 using state from T 2 overlapping transactions are serialisable Slide 22 Slide 24 (T ) (T ) (T ) (T ) (T ) (T ) 1 2 3 2 4 3 • Make sure T v doesn’t read items written by other T i s Why? • Make sure T v doesn’t write items read by other T i s Why? ts WR (x) ts (x) ts(T ) ts WR (x) ts (x) ts(T ) wait until wr 3 wr 3 T commits 2 • Make sure T v doesn’t write items written by other T i s Why? (T ) (T ) (T ) (T ) (T ) 1 4 3 1 2 ➜ Prevent overlapping of validation phases (mutual exclusion) ts WR (x) ts(T ) ts WR (x) ts(T ) 3 3 (T ) (T ) (T ) (T ) 4 3 4 3 O PTIMISTIC C ONTROL 11 O PTIMISTIC C ONTROL 12

Backward validation: ➜ Check committed overlapping transactions Distributed Flat Transaction: ➜ Only have to check if T v read something another T i has written Client ➜ Abort T v if conflict T � Have to keep old write sets Slide 25 Slide 27 Forward validation: ➜ Check not yet committed overlapping transactions ➜ Only have to check if T v wrote something another T i has read ➜ Options on conflict: abort T v , abort T i , wait Server W Server X Server Y Server Z � Read sets of not yet committed transactions may change during validation! Distributed Nested Transaction: Client D ISTRIBUTED T RANSACTIONS T ➜ In distributed system, a single transaction will, in general, involve several servers: • transaction may require several services, • transaction involves files stored on different servers Server Y Server X Slide 26 Slide 28 ➜ All servers must agree to Commit or Abort , and do this T2 T1 atomically. Transaction Management: ➜ Centralised Server M Server N Server O Server P ➜ Distributed T11 T12 T21 T22 D ISTRIBUTED T RANSACTIONS 13 D ISTRIBUTED C ONCURRENCY C ONTROL 14