transactions and concurrency control distribuerade informationssystem, 1dt060, ht 2013 adapted from,...
TRANSCRIPT
![Page 1: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/1.jpg)
Transactions andConcurrency Control
Distribuerade Informationssystem, 1DT060, HT 2013Adapted from, Copyright, Frederik Hermans
![Page 2: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/2.jpg)
Concurrencyconcurrency noun \kən-ˈkə-rən(t)-sē\the simultaneous occurrence of events or circumstances
• Happens at various scales• Enables efficient use of resources
![Page 3: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/3.jpg)
A Christmas example
Your grandmother puts 1000 SEK in your account.
Your uncle puts 500 SEK in your account.
y1=readBalance(Y)g=readBalance(G)g=g-1000y1=y1+1000writeBalance(Y,y1)writeBalance(G,g)
y2=readBalance(Y)u=readBalance(U)u=u-500y2=y2+500writeBalance(Y,y2)writeBalance(U,u)
![Page 4: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/4.jpg)
Uncontrolled concurrency• What if both execute the transfer at the same time?• Operations of the transactions are interleaved
y1=readBalance(Y)g=readBalance(G) y2=readBalance(Y) u=readBalance(U)g=g-1000 u=u-500y1=y1+1000 y2=y2+500writeBalance(Y,y1)writeBalance(G,g) writeBalance(Y,y2) writeBalance(U,u)
Your account is only credited 500 SEK!Oops!
![Page 5: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/5.jpg)
Dealing with concurrency•Uncontrolled
concurrencycan (and has) lead to severeproblems
•Problems often hard toreproduce
•Understanding concurrency is a crucial skill for any designer of a computer system
![Page 6: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/6.jpg)
Outline•Motivation•Transactions & ACID properties• Isolation
- Conflicts & serializability- 2-phase locking- Deadlocks
•Atomicity- 2-phase commit protocol
![Page 7: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/7.jpg)
Transactions•Definition: A transaction is a sequence of
operations that must to be treated as an undivided unit.
•Operations read and write- read(X): access resource X without modifying it- write(X): modify resource X
•A transaction must be either committed or aborted
ServerClient
read(X)read(Y)write(X)write(Y)commit
![Page 8: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/8.jpg)
ACID properties•Desirable properties for transactions
•Atomicity•Consistency• Isolation•Durability
![Page 9: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/9.jpg)
read(X)read(Y)write(X)write(Y)commit
Atomicity•“Either all or none of the effects a transaction are
applied”
•Ancient greek ἄτομος (atomos): indivisible• If a transaction commits, all of its effects are visible• If a transaction aborts, none of its effects are visible
Server
✓✓✓
•After reboot of server, modifications of X must not be visible!
![Page 10: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/10.jpg)
Consistency•“Transactions maintain any internal invariant”
• Invariant: a property of a system that always holds true
•Consistent ⇔ all invariants hold
withdraw 5 trillion SEKfrom account G
Client Serverabort
Transaction would violate the invariant“Balance on G must be larger than 0.”
![Page 11: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/11.jpg)
Isolation•“Concurrent transactions do not interfere
with each other.”
•Each transaction is executed as if it was the only transaction • Initial example
violates isolation property
read(X)read(Y) read(X) read(Z)write(X)write(Y) write(X) write(Z)commit commit
T 1 T 2
![Page 12: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/12.jpg)
Durability•“The effects of a committed transaction are
permanent.”
• If a server crashes and restarts, the effects of all committed transactions must be preserved
•Requires permanent storage (hard disks)
![Page 13: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/13.jpg)
Outline•Motivation•Transactions & ACID properties• Isolation
- Conflicts & serializability- 2-phase locking- Deadlocks
•Atomicity- 2-phase commit protocol
![Page 14: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/14.jpg)
Conflicting operations•What was the problem in the initial example?
- Because of concurrency, T2 overwrote effect of T1- Isolation property was violated
•“Conflicting” operations
•“Conflict” means things may go wrong- They don’t have to!- We cannot get rid of conflicts, but need to handle them
read(X) write(X)
read(X) ✓ Conflict
write(X) Conflict Conflict
T2 does
T1
does
![Page 15: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/15.jpg)
Conflicting operations, example
•Conflicts exist regardless of ordering!
read(X)read(Y)write(X)write(Y)
T1read(X)read(Y)
T2
read(X) read(X)read(Y)write(X) read(Y)write(Y)
Interleaving 1
read(X)read(X)read(Y)write(X)write(Y) read(Y)
Interleaving 2
read(X)read(Y)write(X) read(X)write(Y) read(Y)
Interleaving 3
•Two conflicts- Conflict 1: write(X),
read(X)- Conflict 2: write(Y),
read(Y)
![Page 16: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/16.jpg)
Conflict ordering•Conflicts exist regardless of ordering
- We cannot get rid of them!
•But what does the ordering tell us?
read(X) read(X)read(Y)write(X) read(Y)write(Y)
read(X)read(X)read(Y)write(X)write(Y) read(Y)
read(X)read(Y)write(X) read(X)write(Y) read(Y)
Conflict 1: T2 before T1
Conflict 2: T2 before T1
Conflict 1: T2 before T1
Conflict 2: T1 before T2
Conflict 1: T1 before T2
Conflict 2: T1 before T2Same as T2 T1! Same as T1 T2!???
Something weirdis going on here!
![Page 17: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/17.jpg)
Serializability• If the order on all conflicting operations is
the same, ...- I.e., T1’s operation first for all conflicts- or T2’s operation first for all conflicts
• ... then the transactions are isolated!- they have the same effect as if the transactions
were executed after one another!
•Definition: An interleaving is called serializable if all conflicting operations are executed in the same order
![Page 18: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/18.jpg)
More examplesread(X)read(Y)write(X)write(Y)
T1read(X)read(Y)
T2
•Two conflicts- Conflict 1: write(X),
read(X)- Conflict 2: write(Y),
read(Y) read(X)read(X)read(Y) read(Y)write(X)write(Y)
Interleaving 4
read(X)read(Y)write(X)write(Y) read(X) read(Y)
Interleaving 5
read(X)read(Y) read(X)write(X)write(Y) read(Y)
Interleaving 6
✓Serializable
✓Serializable
XNot serializable
![Page 19: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/19.jpg)
Back to the first exampley1=readBalance(Y)g=readBalance(G) y2=readBalance(Y) u=readBalance(U)g=g-1000 u=u-500y1=y1+1000 y2=y2+500writeBalance(Y,y1)writeBalance(G,g) writeBalance(Y,y2) writeBalance(U,u)•Two conflicts
- Conflict 1: read(Y), write(Y)
- Conflict 2: read(Y), write(Y)
Conflict 1: Grandma before uncleConflict 2: Uncle before grandma
XXNot serializableNot serializable
![Page 20: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/20.jpg)
Non-solution: Global lock• Idea: To execute a transaction, a client acquires a
global lock
•Only two possible interleavings- read(A),read(B),write(A),write(B), read(A),read(B)- read(A),read(B), read(A),read(B),write(A),write(B)
•Good: They are serializable!•Very very bad: Global locks prevent all
concurrency
read(X)read(Y)write(X)write(Y)
T1read(X)read(Y)
T2
Lock - do not enter until T2
is finished.
Lock - do not enter until T1
write are finished.
![Page 21: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/21.jpg)
Locks•System-wide locking disallows concurrency•More fine-grained locks per resource
- Read lock: rlock(X)- Write lock: wlock(X)- Unlock: unlock(X) (for both lock types)
• If lock cannot be acquired, wait until it is available
No lock Read lock Write lock
Read lock ✓ ✓ Wait
Write lock ✓ Wait Wait
Another transaction has
We w
ant
![Page 22: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/22.jpg)
2-phase locking•Each transaction goes through two phases
1.A growing phase, in which it may acquire locks2.A shrinking phase, in which it releases locks
• Always creates a serializable interleaving!N
um
ber
of
lock
s
Time
Phase 1 Phase 2
![Page 23: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/23.jpg)
Example•Execute T1, T2
using2-phase locking
read(X)read(Y)write(X)write(Y)
T1read(X)read(Y)
T2
rlock(X)read(X) rlock(X) read(X)rlock(Y)read(Y)wlock(X) rlock(Y) read(Y) ...
... unlock(X) unlock(Y)write(X)wlock(Y)write(Y)unlock(X)unlock(Y)
Tim
e
Tim
e
wait!
wait!
![Page 24: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/24.jpg)
Deadlock•What if two (or more) transactions wait for
each other to release a lock?
rlock(X)read(X) rlock(Y) read(Y)wlock(Y) wlock(X)wait!
wait!
•Both transactions will wait forever!
![Page 25: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/25.jpg)
Wait-for graph•Wait-for graph
- Each transaction is a node- Edge from T to U if T waits for a lock held by U
•Deadlock occurs if wait-for graph has a cycle
T1
T2
T3
Deadlock!
T1
T2
T3
No deadlock
•To resolve a deadlock, abort any one transaction in the cycle
![Page 26: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/26.jpg)
Beyond 2-phase locking•2-phase locking ensures serializable
interleavings•Problems with 2-phase locking
- Deadlocks can occur- Can be inefficient for write transactions given
long read-only transaction
•Non-locking approaches- Optimistic concurrency control
![Page 27: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/27.jpg)
Quiz 2•Are the following statements true or false?
• If two transactions both execute write(X), then these two write operations are in conflict.
•An interleaving is called serializable if all pairs of conflicting operations are executed in the same order.
•Global locks are an efficient means of ensuring isolation.
•2-phase locking ensures isolation.• If two transactions are in a deadlock, only one
of them will wait, while the other one continues.
![Page 28: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/28.jpg)
Outline•Motivation•Transactions & ACID properties• Isolation
- Conflicts & serializability- 2-phase locking- Deadlocks
•Atomicity- 2-phase commit protocol
![Page 29: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/29.jpg)
Atomicity in distributed systems•Transaction involves multiple servers
Server 1
Server 2
write(X)
write(Y)Coordinator
•Client accesses servers via a coordinator•What about atomicity?
Clientwrite(X)write(Y)
![Page 30: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/30.jpg)
2-phase commit protocol•Client asks coordinator to commit•Must reach consensus on commit or abort
- Even in the presence of failures!
•2-phase commit protocol- Protocol to ensure atomic distributed transactions- Phase 1: Voting- Phase 2: Completion
• (2-phase commit ≠ 2-phase locking)
![Page 31: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/31.jpg)
Phase 1: voting•Coordinator sends “can commit?” message to
servers•A server that cannot commit sends “no”•A server that can commit sends “yes”
- Before it sends “yes”, it must save all modifications to permanent storage
Server 1
Server 2
Coordinator
can commit?
can commit?
no
yes
![Page 32: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/32.jpg)
Phase 2: completion•Coordinator collects votes
(a) Failure or a “no” vote → coordinator sends “do abort” to all servers that have voted “yes”
(b) All “yes” → coordinator sends “do commit” to all servers
(a)Servers handle “do abort” or “do commit”, respectively
![Page 33: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/33.jpg)
Phase 2: completion•Coordinator collects votes
(a) Failure or a “no” vote → coordinator sends “do abort” to all servers that have voted “yes”
- All “yes” → coordinator sends “do commit” to all servers
(a)Servers handle “do abort” or “do commit”, respectively
Server 1
Server 2
Coordinator
no
yesdo abort
do abort
![Page 34: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/34.jpg)
Phase 2: completion•Coordinator collects votes
(a) Failure or a “no” vote → coordinator sends “do abort” to all servers that have voted “yes”
- All “yes” → coordinator sends “do commit” to all servers
(a)Servers handle “do abort” or “do commit”, respectively
Server 1
Server 2
Coordinator
yes
yes
do commit
do commit
![Page 35: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/35.jpg)
Failures•A server crashes (and reboots) before voting
- Server votes “no” after reboot- Or: coordinator times out waiting, sends “do abort”
to all
•A server crashes (and reboots) after voting “no”- No problem
•A server crashes (and reboots) after voting “yes”- Server restores from permanent storage, waits for
instruction from coordinator- Or: coordinator times out waiting, sends “do abort”
to all
•The coordinator crashes after phase 1...
![Page 36: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/36.jpg)
Server uncertainty•Server that voted “yes” cannot abort
- “Yes” means “I promise to commit when you ask me to.”
•Server uncertainty: time between a server’s “yes” vote and the coordinator’s “do commit” or “do abort” request- Server may not unlock resources!
Coordinator yes
can commit?
Server 2do abort
???
![Page 37: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/37.jpg)
Quiz 3•Are the following statements true or false?
•The purpose of the 2-phase commit protocol is to ensure atomicity of distributed transactions.
•2-phase commit is a variant of 2-phase locking.
•The 2-phase commit protocol is unable to cope with server failure.
• In phase 2, the coordinator sends a “do abort” message to all servers if it receives at least one “no” vote.
![Page 38: Transactions and Concurrency Control Distribuerade Informationssystem, 1DT060, HT 2013 Adapted from, Copyright, Frederik Hermans](https://reader036.vdocuments.site/reader036/viewer/2022062517/56649f085503460f94c1d565/html5/thumbnails/38.jpg)
Reading•Coulouris et al., Chapter 16.1 - 16.4•Coulouris et al., Chapter 17.3, 2-phase
commit protocol (without nested transactions)