Distributed Systems Fall 2010 Transactions and concurrency control

Outline • Transactions – Nested transactions • Concurrency control – Locks – Optimistic concurrency control Fall 2010 5 DV 020 3

Transactions • Set of operations performed as a whole – Begin trans – Perform operations – Commit/abort Fall 2010 5 DV 020 4

ACID • Atomicity: “all or nothing” • Consistency: transactions take system from one consistent state to another • Isolation: transactions do not interfere with each other • Durability: committed results of transactions are permanent Fall 2010 5 DV 020 5

Problems with transactions • Transactions are carried out concurrently for higher performance • Problems – Lost update – Inconsistent retrieval • Solution – Serial equivalence • Conflicting operations Fall 2010 5 DV 020 6

Lost update • T 1: A=read(x), write(x, A*10) • T 2: B=read(x), write(x, B*10) • If not properly isolated, we could get the following interleaving: – A=read(x), B=read(x), write(x, A*10), write(x, B*10) – Executing T 1 and T 2 should have increased x by ten times twice, but we lost one of the updates Fall 2010 5 DV 020 7

Inconsistent retrieval • T 1: withdraw(x, 10), deposit(y, 10) • T 2: sum all accounts • Improper interleaving: withdraw(x, 10), sum+=read(x), sum+=read(y), . . . , deposit(y, 10) • The sum will be incorrect, since the 10 that were deposited were neither in x nor in y – the retrieval was inconsistent Fall 2010 5 DV 020 8

Serial equivalence • Serial equivalence: the interleaving of operations is such that the combined effect is the same as if the transactions had been performed (fully) one at a time – Does not mean that we actually perform one transaction at a time, as this would lead to horrible performance Fall 2010 5 DV 020 9

Conflicting operations • If the result depends on the order of execution, operations are in conflict • Read – No conflict • Read – Write (or Write – Read) – Conflict! • Write – Conflict! Fall 2010 5 DV 020 10

Serial equivalence • Definition: – For two transactions to be serially equivalent, it is necessary and sufficient that all pairs of conflicting operations of the two transactions be executed in the same order at all of the objects they both access Fall 2010 5 DV 020 11

Example (serial equivalence) • See Figure 13. 10 in the book © Pearson Education 2005 – Not sequentially consistent • Conflicting operations are handled nicely. . . • . . . but in violation of the requirement that all objects must be handled in the same order Fall 2010 5 DV 020 12

Aborted transactions • Transactions can be aborted for whatever reason – Dirty reads – Premature writes Fall 2010 5 DV 020 13

Dirty reads • T 1 reads a value that T 2 wrote, then commits and later, T 2 aborts – The value is “dirty”, since the update to it should not have happened – T 1 has committed, so it cannot be undone • Real world effects Fall 2010 5 DV 020 14

Handling dirty reads • New rule: let T 1 wait until T 2 commits/aborts! – But if T 2 aborts, we must abort T 1 • . . . and so on: others may depend on T 1 • Better rule: – Transactions are only allowed to read objects that committed transactions have written Fall 2010 5 DV 020 15

Premature writes • “Before images” to recover from bad writes • Let x = 50 initially • T 1: write(x, 10); T 2: write(x, 20) • Let T 1 execute before T 2 • What happens if either aborts? – Order of commit/abort matters! Fall 2010 5 DV 020 16

Handling premature writes • If before images are used, delay writes to objects until other transactions that write to the same object have committed/aborted • Systems that avoid both dirty reads and premature writes are “strict” – Highly desirable! – Tentative versions (local to each transaction) Fall 2010 5 DV 020 17

Nested transactions • Tree-structured transactions – Subtransactions at one level may execute concurrently – Subtransactions may provisionally commit or abort independently, and parent may decide whether to abort or not as a result • Provisional commit is not a proper commit! Fall 2010 5 DV 020 18

Rules for nested transactions • A transaction may commit/abort once all child transactions are completed • When a subtransaction completes, it makes independent choice whether to provisionally commit or abort Fall 2010 5 DV 020 19

Rules for nested transactions • When a parent aborts, so do its children • When a subtransaction aborts, the parent may decide what to do • If the top-level transaction commits, all subtransactions that have provisionally committed may commit as well Fall 2010 5 DV 020 20

Locks • Need an object? Get a lock for it! – Read or write locks, or both (exclusive) • Two-phase locking – Accumulate locks gradually, then release locks gradually • Strict two-phase locking – Accumulate locks gradually, keep them all until completion – Enables “strict” systems • Granularity and tradeoffs Fall 2010 5 DV 020 21

Shared locks • Read locks can be shared • Promote read lock to write lock if no other transactions require a lock • Requesting a write lock when there already read locks, or a read lock when there is already a write lock? – Wait until lock is available Fall 2010 5 DV 020 22

Locks and nested transactions • Isolation – From other sets of nested transactions – From other transactions in own set • Rules: – Parents do not run concurrently with children • Children can temporarily acquire locks from ancestors – Parent inherits locks when child transactions commit – Locks are discarded if child aborts Fall 2010 5 DV 020 23

Deadlocks • Typical deadlock: – Transaction A waits for B, transaction B waits for A • Deadlocks may arise in long chains • Conceptually, construct a wait-for graph – Directed edge between nodes if one waits for the other – Cycles indicate deadlocks • Abort transaction(s) as needed Fall 2010 5 DV 020 24

Handling deadlock • Deadlock prevention – Acquire all locks from the beginning • Bad performance • Not always possible • Deadlock detection – As soon as a lock is requested, check if a deadlock will occur • Bad performance: avoid checking always – Must include algorithm for determining which transaction to abort Fall 2010 5 DV 020 25

Handling deadlock • Lock timeouts – Locks invulnerable for a certain time, then they are vulnerable – Leads to unnecessary aborts • Long-running transactions • Overloaded system – How to decide useful timeout value? Fall 2010 5 DV 020 26

Optimistic concurrency control • Optimistic concurrency control assumes problems happen seldom • Transaction phases – Working • Transaction works with tentative data – Validation • Upon completion, see if transaction may commit or must abort – Update • Write tentative data from committed transactions to permanent storage Fall 2010 5 DV 020 27

Optimistic validation • Use conflict rules from earlier! • Validate one transaction at a time against others • Transactions are numbered (not to be confused with IDs) as they start – Working phase for transaction X is not over until transaction X-1 has completed Fall 2010 5 DV 020 28

Backward validation • Check read set against write set of transactions that: – were active at the same time as the transaction currently being validated; and – have already committed • If overlap is found, then current transaction must be aborted Fall 2010 5 DV 020 29

Forward validation • Check write set against read set of transactions that: – Are currently active • Note that read sets of active transactions may change during validation • If overlap is found, we can choose which transaction(s) to abort Fall 2010 5 DV 020 30

Comparison of optimistic CC • Size of read/write sets – Read sets are usually bigger • Choice of transaction to abort – Linked to starvation • Overhead – Backward requires old write sets – Forward may need to re-run each time the read set for any active transaction changes Fall 2010 5 DV 020 31

Comparison of concurrency control schemes • Pessimistic CC – Transactions wait for locks –. . . and yet, can still be aborted • For systems with many CC-related issues – Pessimistic will give a more stable quality of service – Optimistic will abort a large number of transactions and requires substantial work Fall 2010 5 DV 020 32

Summary • Transactions – ACID – Nested transactions – Problems • • Lost update Inconsistent retrieval Dirty read Premature writes – Serial equivalence – Strictness Fall 2010 5 DV 020 33

Summary • Concurrency control – Pessimistic (locks) • Deadlocks – Optimistic • Backward and forward validation – Comparison of the schemes Fall 2010 5 DV 020 34