TRANSACTIONS (AND EVENT- DRIVEN PROGRAMMING) EE324
Jan 02, 2016
TRANSACTIONS (AND EVENT-DRIVEN PROGRAMMING)
EE324
2
Concurrency Control
General organization of managers for handling transactions.
3
Two-phase locking is “pessimistic”
Acts to prevent non-serializable schedules from arising: pessimistically assumes conflicts are fairly likely
Can deadlock, e.g. T1 reads x then writes y; T2 reads y then writes x. This doesn’t always deadlock but it is ca-pable of deadlocking Overcome by aborting if we wait for too long, Or by designing transactions to obtain locks in a known and
agreed upon ordering
4
Transactions T and U with exclusive locks
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
5
Schemes for Concurrency control
Locking Optimistic concurrency control (CDK516.5) Time-stamp based concurrency control (not going to
cover)
6
Optimistic Concurrency Control
Drawbacks of locking Overhead of lock maintenance Deadlocks Reduced concurrency
Optimistic Concurrency Control In most applications, likelihood of conflicting accesses by
concurrent transactions is low Transactions proceed as though there are no conflicts
7
Optimistic Concurrency Control
Three phases: Working Phase – transactions read and write private
copies of objects (most recently committed) Validation Phase – Once transaction is done, the trans-
action is validated to establish whether or not its opera-tions on objects conflict with operations of other transac-tions on the same object. If not conflict, can commit; else some form of conflict resolution is needed and the trans-action may abort.
Update Phase – if commit, private copies are used to make permanent change.
8
Validation of transactions
Earlier committed
transactions
Working Validation Update
T1
Tv
Transaction
being validated
T2
T3
Later active
transactions
active1
active2
Validation – conflict detection
Tv Ti Rule
Write Read Ti must not read objects written by Tv
Read Write Tv must not read objects written by Ti
Write Write Ti must not write objects written by Tv and Tv must not write objects written by Ti
Optimistic concurrency control
Transactions are numbered. Validation and update occurs in side the critical section. (Satisfies
rule 3) Backward validation
Rule 1 is satisfied because all read operations of earlier overlapping trans-actions were performed before the validation of Tv started; they cannot be affected by Tv’s write.
Read set of Tv must be compared with the write sets of T2 and T3. (Rule 2) In other words, the read set of the transaction being validated is compared
with the write set of other overlapping transactions that have already committed.
Thus, we need to keep the write set of T2 and T3 for a while after their commit.
11
Today's Lecture
Distributed transactions
12
Distributed Transactions
Motivation Provide distributed atomic operations at multiple servers
that maintain shared data for clients Provide recoverability from server crashes
Properties Atomicity, Consistency, Isolation, Durability (ACID)
Concepts: commit, abort, distributed commit
13
Transactions in distributed systems
Main issue that arises is that now we can have multiple database servers that are touched by one transaction
Reasons? Data spread around: each owns subset Could have replicated some data object on multiple servers,
e.g. to load-balance read access for large client set Might do this for high availability
14
Atomic Commit Protocols
The atomicity of a transaction requires that when a dis-tributed transaction comes to an end, either all of its operations are carried out or none of them
One phase commit Coordinator tells all participants (servers) to commit
Keep on repeating it until all participants reply If a participant cannot commit (say because of concurrency con-
trol), no way to inform coordinator. Also, no way for the coordina-tor to abort.
The two-phase commit protocol (2PC)
Designed to allow any participant to abort its part of transaction
But this means, the whole transaction must be aborted Why?
First phase: all participants vote (abort or commit). If voted commit, make all changed permanent (durability) and go to prepared state. Log this fact. Participants will eventually commit (if the coordinator says
so) even it crashes. Second phase: Joint decision
16
The two-phase commit protocol - 1
Phase 1 (voting phase): 1. The coordinator sends a canCommit? (VOTE_REQUEST)
request to each of the participants in the transaction.2. When a participant receives a canCommit? request it
replies with its vote Yes (VOTE_COMMIT) or No (VOTE_ABORT) to the coordinator. Before voting Yes, it prepares to commit by saving objects in permanent stor-age. If the vote is No the participant aborts immediately.
17
The two-phase commit protocol - 2
Phase 2 (completion according to outcome of vote):3. The coordinator collects the votes (including its own).
(a)If there are no failures and all the votes are Yes the coordinator decides to commit the transaction and sends a doCommit (G-LOBAL_COMMIT) request to each of the participants.
(b)Otherwise the coordinator decides to abort the transaction and sends doAbort (GLOBAL_ABORT) requests to all participants that voted Yes.
4. Participants that voted Yes are waiting for a doCommit or doAbort re-quest from the coordinator. When a participant receives one of these messages it acts accordingly and in the case of commit, makes a have-Committed call as confirmation to the coordinator.
18
Communication in two-phase commit protocol
canCommit?
Yes
doCommit
haveCommitted
Coordinator
1
3
(waiting for votes)
committed
done
prepared to commit
step
Participant
2
4
(uncertain)
prepared to commit
committed
statusstepstatus
19
Commit protocol illustrated
ok to commit?
20
Commit protocol illustrated
ok to commit?
ok with uscommit
21
Operations for two-phase commit pro-tocol
canCommit?(trans)-> Yes / NoCall from coordinator to participant to ask whether it can commit a transaction. Parti-cipant replies with its vote.
doCommit(trans) Call from coordinator to participant to tell participant to commit its part of a transaction.
doAbort(trans) Call from coordinator to participant to tell participant to abort its part of a transaction.
haveCommitted(trans, participant) Call from participant to coordinator to confirm that it has committed the transaction.
getDecision(trans) -> Yes / NoCall from participant to coordinator to ask for the decision on a transaction after it has voted Yes but has still had no reply after some delay. Used to recover from server crash or delayed messages.
22
Two-Phase Commit protocol – 3 (TV sec 8.5) actions by coordinator:
while START _2PC to local log;multicast VOTE_REQUEST to all participants;while not all votes have been collected { wait for any incoming vote; if timeout { write GLOBAL_ABORT to local log; multicast GLOBAL_ABORT to all participants; exit; } record vote;}if all participants sent VOTE_COMMIT and coordinator votes COMMIT{ write GLOBAL_COMMIT to local log; multicast GLOBAL_COMMIT to all participants;} else { write GLOBAL_ABORT to local log; multicast GLOBAL_ABORT to all participants;}
23
Two-Phase Commit protocol - 4
actions by participant:write INIT to local log;
wait for VOTE_REQUEST from coordinator;if timeout { write VOTE_ABORT to local log; exit;}if participant votes COMMIT { write VOTE_COMMIT to local log; send VOTE_COMMIT to coordinator; wait for DECISION from coordinator; if timeout { multicast DECISION_REQUEST to other participants; wait until DECISION is received; /* remain blocked */ write DECISION to local log; } if DECISION == GLOBAL_COMMIT write GLOBAL_COMMIT to local log; else if DECISION == GLOBAL_ABORT write GLOBAL_ABORT to local log;} else { write VOTE_ABORT to local log; send VOTE ABORT to coordinator;}
24
Two-Phase Commit protocol - 5
a) The finite state machine for the coordinator in 2PC.b) The finite state machine for a participant.
Coordinator and participants have blocking state. When a failure occurs, other process may be indefinitely waiting.
There needs to be a timeout mechanism.
25
Two Phase Commit Protocol - 6
Timeouts ‘Wait’ in Coordinator – use a time-out mechanism to detect participant
crashes. Send GLOBAL_ABORT ‘Init’ in Participant – Can also use a time-out and send VOTE_ABORT ‘Ready’ in Participant P – abort is not an option (since already voted to
COMMIT and so coordinator might eventually send GLOBAL_COMMIT). Can contact another participant Q and choose an action based on its state.
State of Q Action by PCOMMIT Transition to COMMIT
ABORT Transition to ABORT
INIT Both P and Q transition to ABORT (Q sends VOTE_ABORT)
READY Contact more participants. If all participants are ‘READY’, must wait for coordinator to recover
Two Phase Commit Protocol - 7
Recovery To ensure that a process can actually recover, it must save
its state to persistent storage. If a participant was in INIT (before crash), it can safely de-
cide to locally abort when it recovers and inform the coordi-nator.
If it was COMMIT and ABORT, retransmit its decision to the coordinator.
If it was READY, contact other participant Q (Send DECI-SION_REQUEST), similar to the timeout situation.
27
Two-Phase Commit protocol - 8
actions for handling decision requests:
/* executed by separate thread */
while true { wait until any incoming DECISION_REQUEST is received; /* remain blocked */ read most recently recorded STATE from the local log; if STATE == GLOBAL_COMMIT send GLOBAL_COMMIT to requesting participant; else if STATE == INIT or STATE == GLOBAL_ABORT send GLOBAL_ABORT to requesting participant; else skip; /* participant remains blocked */
28
Three Phase Commit protocol - 1
Problem with 2PC If coordinator crashes, participants cannot reach a decision,
stay blocked until coordinator recovers Three Phase Commit (3PC): proof in [SS 1983]
There is no single state from which it is possible to make a transition directly to either COMMIT or ABORT states
There is no state in which it is not possible to make a final decision, and from which a transition to COMMIT can be made
29
Three-Phase Commit protocol - 2
a) Finite state machine for the coordinator in 3PC
b) Finite state machine for a participant
30
Three Phase Commit Protocol - 3Recovery ‘Wait’ in Coordinator – same ‘Init’ in Participant – same ‘PreCommit’ in Coordinator – Some participant has crashed but we know it wanted
to commit. GLOBAL_COMMIT the application knowing that once the participant re-covers, it will commit.
‘Ready’ or ‘PreCommit’ in Participant P – (i.e. P has voted to COMMIT)State of Q Action by PPRECOMMIT Transition to PRECOMMIT. If all participants in
PRECOMMIT and form a majority, then COMMIT the transaction
ABORT Transition to ABORT
INIT Both P (in READY) and Q transition to ABORT (Q sends VOTE_ABORT). It can be shown that no other participants can be in PRECOMMIT
READY Contact more participants. If can contact a majority and they are in ‘Ready’, then ABORT the transaction.If the participants contacted in ‘PreCommit’ it is safe to COMMIT the transaction
Note: if any participant is in state PRECOMMIT, it is impossible for any other participant to be in any state other than READYor PRECOMMIT.
Things we have learned so far…
ACID Concurrency control Distributed atomic commit
32
Two Views of Distributed Systems
Optimist: A distributed system is a collection of inde-pendent computers that appears to its users as a single coherent system
Pessimist: “You know you have one when the crash of a computer you’ve never heard of stops you from get-ting any work done.” (Lamport)
33
Recurring Theme
Academics like: Clean abstractions Strong semantics Things that prove they are smart
Users like: Systems that work (most of the time) Systems that scale Consistency per se isn’t important
Eric Brewer had the following observations
34
A Clash of Cultures
Classic distributed systems: focused on ACID semantics (transac-tion semantics) Atomicity: either the operation (e.g., write) is performed on all replicas
or is not performed on any of them Consistency: after each operation all replicas reach the same state Isolation: no operation (e.g., read) can see the data from another oper-
ation (e.g., write) in an intermediate state Durability: once a write has been successful, that write will persist in-
definitely
Modern Internet systems: focused on BASE Basically Available Soft-state (or scalable) Eventually consistent
ACID vs BASE
ACID
Strong consistency for transactions highest priority Availability less important Pessimistic Rigorous analysis Complex mechanisms
BASE
Availability and scaling highest priorities Weak consistency Optimistic Best effort Simple and fast
35
36
Why Not ACID+BASE?
What goals might you want from a system? C, A, P
Strong Consistency: all clients see the same view, even in the presence of updates
High Availability: all clients can find some replica of the data, even in the presence of failures
Partition-tolerance: the system properties hold even when the system is partitioned
37
CAP Theorem [Brewer]
You can only have two out of these three properties
The choice of which feature to discard determines the nature of your system
38
Consistency and Availability
Comment: Providing transactional semantics requires all functioning nodes to be in
contact with each other (no partition)
Examples: Single-site and clustered databases Other cluster-based designs
Typical Features: Two-phase commit Cache invalidation protocols Classic DS style
39
Partition-Tolerance and Availability
Comment: Once consistency is sacrificed, life is easy….
Examples: DNS Web caches Practical distributed systems for mobile environments: Coda, Bayou
Typical Features: Optimistic updating with conflict resolution This is the “Internet design style” TTLs and lease cache management
40
Voting with their Clicks
In terms of large-scale systems, the world has voted with their clicks: Consistency less important than availability and partition-
tolerance