Distributed Systems Fall 2010 Transactions and concurrency control.
-
date post
19-Dec-2015 -
Category
Documents
-
view
220 -
download
1
Transcript of Distributed Systems Fall 2010 Transactions and concurrency control.
Fall 2010 5DV020 3
Outline
• Transactions– Nested transactions
• Concurrency control– Locks– Optimistic concurrency control
Fall 2010 5DV020 4
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 2010 55DV020
Fall 2010 5DV020 6
Problems with transactions
• Transactions are carried out concurrently for higher performance
• Problems– Lost update– Inconsistent retrieval
• Solution– Serial equivalence
• Conflicting operations
Fall 2010 5DV020 7
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 2010 5DV020 8
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 2010 5DV020 9
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 5DV020 10
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 2010 5DV020 11
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 5DV020 12
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 5DV020 13
Aborted transactions
• Transactions can be aborted for whatever reason– Dirty reads– Premature writes
Fall 2010 5DV020 14
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 2010 5DV020 15
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 2010 5DV020 16
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 2010 5DV020 17
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 5DV020 18
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 5DV020 19
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 2010 205DV020
Fall 2010 5DV020 21
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 5DV020 22
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 2010 5DV020 23
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 5DV020 24
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 5DV020 25
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 5DV020 26
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 5DV020 27
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 5DV020 28
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 5DV020 29
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 5DV020 30
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 5DV020 31
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 5DV020 32
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 5DV020 33
Summary
• Transactions– ACID– Nested transactions– Problems
• Lost update• Inconsistent retrieval• Dirty read• Premature writes
– Serial equivalence– Strictness