1
Distribuerede systemer og sikkerhed – 18. marts 2002
From Coulouris, Dollimore and Kindberg
Distributed Systems: Concepts and Design
Edition 3, © Addison-Wesley 2001
Presentation based on slides for the book:
Slides modified by Jens B Jorgensen, University of Aarhus
2
Chapter 12: Transactions and Concurrency Control
From Coulouris, Dollimore and Kindberg
Distributed Systems: Concepts and Design
Edition 3, © Addison-Wesley 2001
3
Transactions – basics
System model: One server, multiple clients.Goal: Objects at server remain consistent.Failure model: Server crashes, omission failures,
arbitrary delays.Transaction:
Set of operations on objects to be performed as an indivisible unit by the server.
Server must guarantee that either the entire transaction is carried out and the results recorded in permanent storage or (if crash) its effects are completely erased.
Essential properties: ACID.
4
Transactions – bank server
deposit(amount)deposit amount in the account
withdraw(amount)withdraw amount from the account
getBalance() -> amountreturn the balance of the account
setBalance(amount)set the balance of the account to amount
create(name) -> accountcreate a new account with a given name
lookUp(name) -> account return a reference to the account with the given name
branchTotal() -> amountreturn the total of all the balances at the branch
Operations of the Branch interface
Operations of the Account interface
5
Transactions – a client’s banking transaction
Transaction T:a.withdraw(100);b.deposit(100);c.withdraw(200);b.deposit(200);
6
Transactions – life histories
Successful Aborted by client Aborted by server
openTransaction openTransaction openTransactionoperation operation operation operation operation operation
server abortstransaction
operation operation operation ERRORreported to client
closeTransaction abortTransaction
Coordinator interface:openTransaction() -> trans;closeTransaction(trans) -> (commit,abort);abortTransaction(trans);
7
Concurrent transactions – the lost update problem
Transaction T :
balance = b.getBalance();b.setBalance(balance*1.1);a.withdraw(balance/10)
Transaction U:
balance = b.getBalance();b.setBalance(balance*1.1);c.withdraw(balance/10)
balance = b.getBalance(); $200
balance = b.getBalance(); $200
b.setBalance(balance*1.1); $220
b.setBalance(balance*1.1); $220
a.withdraw(balance/10) $80
c.withdraw(balance/10) $280
8
Concurrent transactions – the inconsistent retrievals problem
Transaction V:
a.withdraw(100)b.deposit(100)
Transaction W:
aBranch.branchTotal()
a.withdraw(100); $100
total = a.getBalance() $100
total = total+b.getBalance() $300
total = total+c.getBalance()
b.deposit(100) $300
9
Concurrent transactions – serial equivalence
If “correct” transactions are done one at a time in some order, the combined effect will also be correct.
A serially equivalent interleaving: An interleaving of the operations of transactions in which the combined effect is the same as if the transactions had been performed one at a time in some order.
Serial equivalence prevents lost updates and inconsistent retrievals.
10
Concurrent transactions – a serially equivalent interleaving of T and U
Transaction T:
balance = b.getBalance()b.setBalance(balance*1.1)a.withdraw(balance/10)
Transaction U:
balance = b.getBalance()b.setBalance(balance*1.1)c.withdraw(balance/10)
balance = b.getBalance() $200
b.setBalance(balance*1.1) $220balance = b.getBalance() $220
b.setBalance(balance*1.1) $242
a.withdraw(balance/10) $80 c.withdraw(balance/10) $278
11
Concurrent transactions – a serially equivalent interleaving of V and W
Transaction V: a.withdraw(100);b.deposit(100)
Transaction W:
aBranch.branchTotal()
a.withdraw(100); $100
b.deposit(100) $300
total = a.getBalance() $100
total = total+b.getBalance() $400
total = total+c.getBalance()...
12
Concurrent transactions – conflicting operations
Two operations conflict iff their combined effect depends on the order in which they are executed.
For two transactions to be executed 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.
13
Concurrent transactions – read and write operation conflict rules
Operations of differenttransactions
Conflict Reason
read read No Because the effect of a pair of read operationsdoes not depend on the order in which they areexecuted
read write Yes Because the effect of a read and a write operationdepends on the order of their execution
write write Yes Because the effect of a pair of write operationsdepends on the order of their execution
14
Concurrent transactions – interleaving of operations of transactions T and U
Transaction T: Transaction U:
x = read(i)
write(i, 10)y = read(j)
write(j, 30)
write(j, 20)z = read (i)
Serially equivalent?
15
Aborting transactions – dirty read
Transaction T:
a.getBalance()a.setBalance(balance + 10)
Transaction U:
a.getBalance()a.setBalance(balance + 20)
balance = a.getBalance() $100
a.setBalance(balance + 10) $110
balance = a.getBalance() $110
a.setBalance(balance + 20) $130
commit transaction
abort transaction
16
Aborting transactions – premature writes
Transaction T:
a.setBalance(105)
Transaction U:
a.setBalance(110)
$100
a.setBalance(105) $105
a.setBalance(110) $110
17
Aborting transactions – strict execution
A transaction delays both read and write operations on an object, until all transactions that previously wrote that object have either committed or aborted.
Other issues: Cascading aborts. Tentative versions.
18
Nested transactions
T : top-level transactionT1 = openSubTransaction T2 = openSubTransaction
openSubTransaction openSubTransactionopenSubTransaction
openSubTransaction
T1 : T2 :
T11 : T12 :
T211 :
T21 :
prov.commit
prov. commit
abort
prov. commitprov. commit
prov. commit
commit
19
Locks – example
Transaction T: balance = b.getBalance()b.setBalance(bal*1.1)a.withdraw(bal/10)
Transaction U:
balance = b.getBalance()b.setBalance(bal*1.1)c.withdraw(bal/10)
Operations Locks Operations Locks
openTransactionbal = b.getBalance() lock B
b.setBalance(bal*1.1) openTransaction
a.withdraw(bal/10) lock A bal = b.getBalance() waits for T’slock on B
closeTransaction unlock A, B lock B
b.setBalance(bal*1.1)
c.withdraw(bal/10) lock C
closeTransaction unlock B, C
20
Locks – locking schemes
Exclusive locks: The server attempts to lock any object that is about to be used by any
operation of a client’s transaction. If a client requests access to an object that is already locked, the
request is suspended and the client must wait. Two-phase locking:
A transaction is not allowed any new locks after it has released a lock. Growing phase: New locks are acquired. Shrinking phase: Locks are released.
Strict two-phase locking: Any locks acquired during the progress of a transaction are held until the transaction commits or aborts.
Concurrency control granularity an import issue.
21
Locks – read and write locks
Allow several concurrent transactions to read an object.
Ensure exclusive access for writing.
For one object Lock requested read write
Lock already set none OK OK
read OK wait
write wait wait
22
Locks – read and write locks in strict two-phase locking
1. When an operation accesses an object within a transaction:(a) If the object is not already locked, it is locked and the operation
proceeds.(b) If the object has a conflicting lock set by another transaction, the
transaction must wait until it is unlocked.(c) If the object has a non-conflicting lock set by another transaction, the
lock is shared and the operation proceeds.(d) If the object has already been locked in the same transaction, the lock
will be promoted if necessary and the operation proceeds. (Where promotion is prevented by a conflicting lock, rule (b) is used.)
2. When a transaction is committed or aborted, the server unlocks all objects it locked for the transaction.
23
Deadlocks – basics
Transaction T Transaction U
Operations Locks Operations Locks
a.deposit(100); write lock A
b.deposit(200) write lock B
b.withdraw(100)waits for U’s a.withdraw(200); waits for T’s
lock on B lock on A
Deadlock: Each member of a group of transactions is waiting forsome other member to release a lock.
24
Deadlocks – wait-for graphs
B
A
Waits for
Held by
Held by
T UU T
Waits for
Representation of waiting relationship between ongoing transactions.Deadlocks correpond to cycles.To recover from a deadlock, break a cycle.
25
Deadlocks – resolution via timeouts
Transaction T Transaction U
Operations Locks Operations Locks
a.deposit(100); write lock A
b.deposit(200) write lock B
b.withdraw(100)
waits for U’s a.withdraw(200); waits for T’s
lock on B lock on A (timeout elapses) T’s lock on A becomes vulnerable,
unlock A, abort Ta.withdraw(200); write locks A
unlock A, B
26
Optimistic concurrency control – motivation
Locking may result in overhead, deadlocks, and reduced concurrency.
Observation: In most applications, the likelihood of two clients’ transactions accessing the same object is low.
Method: Go ahead, but do check upon closeTransaction!
27
Optimistic concurrency control – transaction phases
Working phase: Each transaction has a tentative version of each of the objects that it
updates. Read set and write set maintained.
Validation phase: When the closeTransaction request is received, the transaction is
validated to establish whether or not its operations on objects conflict with operations of other transactions.
If success the commit. If fail then some transaction must be aborted.
Update phase: Record changes to tentative versions as permanent.
28
Optimistic concurrency control – overall validation strategy
Use read-write conflict rules.For a given transaction, ensure serial equivalence
with all other overlapping transactions.Transactions are assigned increasing numbers when
they enter validation phase.Assumption: At any time, at most one transaction is
in the validation and update phase.
29
Optimistic concurrency control – validation rules
Tv Ti Rule
write read 1. Ti must not read objects written by Tv
read write 2. Tv must not read objects written by Ti
write write 3. Ti must not write objects written by Tv and
Tv mustnot write objects written by Ti
Serializability of transactions Tv and Ti:
30
Optimistic concurrency control – validation algorithms
Backward validation of transaction Tv
boolean valid = true;for (int Ti = startTn+1; Ti <= finishTn; Ti++){
if (read set of Tv intersects write set of Ti) valid = false;}
Forward validation of transaction Tv
boolean valid = true;for (int Tid = active1; Tid <= activeN; Tid++){
if (write set of Tv intersects read set of Tid) valid = false;}
31
Optimistic concurrency control – validation example
Earlier committedtransactions
Working Validation Update
T1
TvTransactionbeing validated
T2
T3
Later activetransactions
active1
active2
32
Summary
Transactions: Concurrent transactions (serial equivalence). Aborting transactions. (Nested transactions).
Locks: Two-phase locking. Strict two phase-locking. Deadlocks.
Optimistic concurrency control: Backward validation. Forward validation.