distributed data with acid transactions · 2005. 2. 24. · cs530 s05 distributed data with acid...
TRANSCRIPT
CS530 S05
Distributed Data with ACID Transactions
• 3-tier application with data distributed across multiple DBMSs
• Not replicating the data (yet)
DBMS1
...
ApplicationServer
Clients
DBMS2
CS530 S05
Why Do This?
• Legacy systems using separate DBMSs
• have no choice ...
•• Performance improvement for certain
workloads
• mostly read-only transactions confined to a single site
•• Transactional messaging systems
• later
CS530 S05
Why Not Do This?
• Every DBMS / resource manager is a single point of failure
• So this never improves availability
CS530 S05
The Difficult Issue
• Want ACID transaction properties for data distributed across multiple DBMSs
• The DBMSs cannot just commit sequentially
• failure during commit sequence would lead to consistency violation
• Two-Phase Commit protocol (2PC)
• [BN97] Ch 9
• There is a Three-Phase protocol (3PC)
• slightly more reliable but more complex
• rarely used
CS530 S05
Overview of 2PC
• A coordinator is in charge of the transaction
• DBMSs (participants) follow coordinator’s instructions
• Two phases (!):
• Participants vote to commit or abort
• Coordinator counts the votes
• Commit only if every participant votes yes!
CS530 S05
2-Phase Commit
• Phase 1:
• Coordinator sends PREPARE to all participants and waits for responses
• Participants reply YES or NO, or fail to reply
CS530 S05
2-Phase Commit
• Phase 2:
• Coordinator decides YES iff received YES votes from all participants
• Coordinator sends decision to all participants
• Participants reply DONE
• Coordinator frees resources after receiving DONE from all participants
CS530 S05
2-Phase Commit - Blocking
• Correctness:
• After voting NO participant may abort
• After voting YES participant may not commit or abort until receiving the coordinator decision -- in doubt
• After voting YES participant must be able to commit even after failure and recovery
• What if coordinator fails while some participants are in doubt? Blocked!
CS530 S05
2-Phase Commit - Theorems
• For every possible distributed commit protocol, a communication failure can cause a participant to become blocked.
• proof related to the famous “FLP” (Fisher, Lynch, Patterson)impossibility proof.
CS530 S05
2-Phase Commit - Theorems
• No distributed commit protocol can guarantee independent recovery (recovery without cooperation from coordinator or other participants) of a failed participant.
CS530 S05
Logging in 2PC
• Coordinator and participants must log enough information to enable recovery if a failure occurs during execution of the 2PC protocol
• Durable log: assume after a failure every logged record will be recoverable
CS530 S05
Logging in 2PC (YES)
Log a START record
Log a COMMIT record
Log a DONE record
Log a PREPARED record
Log a COMMITTED record
PREPARE
YES
YES
DONE
CS530 S05
Logging in 2PC (NO)
Log a START record
Log an ABORT record
Log a DONE record
Log a NO record
Log an ABORTED record
PREPARE
NO
NO
DONE
CS530 S05
Error Handling - Coordinator
• Broadcast PREPARE
• No error possible
• Receive replies from all participants
• Any replies timeout => assume NO
• Decide to commit or abort
• No error possible
• Broadcast decision (COMMIT or ABORT)
• No error possible
CS530 S05
Error Handling - Coordinator
• Receive DONE from all participants
• Timeout => re-solicit DONE messages from all participants (infinite loop)
• Free all resources associated with transaction
• No error possible
CS530 S05
Error Handling - Participant
• Receive PREPARE from coordinator
• Timeout without PREPARE request => abort the transaction unilaterally
• Txn mentioned in PREPARE does not exist => just ignore the request
• Prepare the transaction for commit
• No error possible
• Result is commit vote (YES or NO)
CS530 S05
Error Handling - Participant
• Send vote (YES or NO)
• No error possible
• Receive decision
• Timeout => blocked!
• Implement the decision (commit or abort) and send DONE
• No error possible
• Note this is a key property of 2PC!
CS530 S05
Recovery
Log a START record
Log a COMMIT record
Log a DONE record
Log a PREPARED record
Log a COMMITTED record
PREPARE
YES
YES
DONE
CS530 S05
Recovery
Log a START record
Log an ABORT record
Log a DONE record
Log a NO record
Log an ABORTED record
PREPARE
NO
NO
DONE
CS530 S05
Recovery - Coordinator
• No START in log
• No action required
• participants eventually abort
• No COMMIT/ABORT in log
• Send NO
• participants abort even if decision was YES
• No DONE in log
• Send decision from log
• may be a resend
• DONE in log
• No action required
CS530 S05
Recovery - Participant
• No PREPARED record in log
• Abort unilaterally
• could not have voted YES with no PREPARED log record
• No COMMITED/ABORTED in log
• Execute “Termination Protocol”
• this is the hard case
• COMMITED/ABORTED in log
• Send DONE
• may be resend
CS530 S05
A Simple Termination Protocol
• Reestablish communication with coordinator (wait indefinitely for this)
• Resend vote
• Coordinator will eventually resend decision
• cannot have forgotten the txn as it has not received a DONE message!
CS530 S05
“XA” Resource Interfaces
• Vendor-independent 2PC protocol specification
• Supported by many RDBMS systems, JMS, ...
• distributed commit of data on DBMSs from multiple vendors!
• Important part of J2EE