Distributed Systems Fall 2010 Transactions and concurrency control

Fall 20105DV0203 Outline Transactions –Nested transactions Concurrency control –Locks –Optimistic concurrency control

Fall 20105DV0204 Transactions Set of operations performed as a whole –Begin trans –Perform operations –Commit/abort

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 DV020

Fall 20105DV0206 Problems with transactions Transactions are carried out concurrently for higher performance Problems –Lost update –Inconsistent retrieval Solution –Serial equivalence Conflicting operations

Fall 20105DV0207 Lost update T1: A=read(x), write(x, A*10) T2: 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 T1 and T2 should have increased x by ten times twice, but we lost one of the updates

Fall 20105DV0208 Inconsistent retrieval T1: withdraw(x, 10), deposit(y, 10) T2: 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 20105DV0209 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 20105DV02010 Conflicting operations If the result depends on the order of execution, operations are in conflict Read – Read –No conflict Read – Write (or Write – Read) –Conflict! Write – Write –Conflict!

Fall 20105DV02011 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 20105DV02012 Example (serial equivalence) See Figure 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 20105DV02013 Aborted transactions Transactions can be aborted for whatever reason –Dirty reads –Premature writes

Fall 20105DV02014 Dirty reads T1 reads a value that T2 wrote, then commits and later, T2 aborts –The value is “dirty”, since the update to it should not have happened –T1 has committed, so it cannot be undone Real world effects

Fall 20105DV02015 Handling dirty reads New rule: let T1 wait until T2 commits/aborts! –But if T2 aborts, we must abort T1...and so on: others may depend on T1 Better rule: –Transactions are only allowed to read objects that committed transactions have written

Fall 20105DV02016 Premature writes “Before images” to recover from bad writes Let x = 50 initially T1: write(x, 10); T2: write(x, 20) Let T1 execute before T2 What happens if either aborts? –Order of commit/abort matters!

Fall 20105DV02017 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 20105DV02018 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 20105DV02019 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

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 DV020

Fall 20105DV02021 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 20105DV02022 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 are already read locks, or a read lock when there is already a write lock? –Wait until lock is available

Fall 20105DV02023 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 20105DV02024 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 20105DV02025 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 20105DV02026 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 20105DV02027 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 20105DV02028 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 20105DV02029 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 20105DV02030 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 20105DV02031 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 20105DV02032 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 20105DV02033 Summary Transactions –ACID –Nested transactions –Problems Lost update Inconsistent retrieval Dirty read Premature writes –Serial equivalence –Strictness

Fall 20105DV02034 Summary Concurrency control –Pessimistic (locks) Deadlocks –Optimistic Backward and forward validation –Comparison of the schemes