1 distribuerede systemer og sikkerhed – 18. marts 2002 zfrom coulouris, dollimore and kindberg...
TRANSCRIPT
![Page 1: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/1.jpg)
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
![Page 2: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/2.jpg)
2
Chapter 12: Transactions and Concurrency Control
From Coulouris, Dollimore and Kindberg
Distributed Systems: Concepts and Design
Edition 3, © Addison-Wesley 2001
![Page 3: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/3.jpg)
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.
![Page 4: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/4.jpg)
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
![Page 5: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/5.jpg)
5
Transactions – a client’s banking transaction
Transaction T:a.withdraw(100);b.deposit(100);c.withdraw(200);b.deposit(200);
![Page 6: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/6.jpg)
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);
![Page 7: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/7.jpg)
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
![Page 8: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/8.jpg)
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
![Page 9: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/9.jpg)
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.
![Page 10: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/10.jpg)
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
![Page 11: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/11.jpg)
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()...
![Page 12: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/12.jpg)
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.
![Page 13: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/13.jpg)
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
![Page 14: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/14.jpg)
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?
![Page 15: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/15.jpg)
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
![Page 16: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/16.jpg)
16
Aborting transactions – premature writes
Transaction T:
a.setBalance(105)
Transaction U:
a.setBalance(110)
$100
a.setBalance(105) $105
a.setBalance(110) $110
![Page 17: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/17.jpg)
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.
![Page 18: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/18.jpg)
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
![Page 19: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/19.jpg)
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
![Page 20: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/20.jpg)
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.
![Page 21: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/21.jpg)
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
![Page 22: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/22.jpg)
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.
![Page 23: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/23.jpg)
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.
![Page 24: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/24.jpg)
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.
![Page 25: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/25.jpg)
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
![Page 26: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/26.jpg)
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!
![Page 27: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/27.jpg)
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.
![Page 28: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/28.jpg)
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.
![Page 29: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/29.jpg)
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:
![Page 30: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/30.jpg)
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;}
![Page 31: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/31.jpg)
31
Optimistic concurrency control – validation example
Earlier committedtransactions
Working Validation Update
T1
TvTransactionbeing validated
T2
T3
Later activetransactions
active1
active2
![Page 32: 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley](https://reader035.vdocuments.site/reader035/viewer/2022081516/56649d0f5503460f949e566f/html5/thumbnails/32.jpg)
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.