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

Fall 2010 5DV020 34

Summary

• Concurrency control– Pessimistic (locks)

• Deadlocks

– Optimistic• Backward and forward validation

– Comparison of the schemes