Distributed DBMS - Commit
Protocols
In a local database system, for committing a transaction, the
transaction manager has to only convey the decision to commit to the
recovery manager. However, in a distributed system, the transaction
manager should convey the decision to commit to all the servers in the
various sites where the transaction is being executed and uniformly enforce
the decision. When processing is complete at each site, it reaches the
partially committed transaction state and waits for all other transactions to
reach their partially committed states. When it receives the message that all
the sites are ready to commit, it starts to commit. In a distributed system,
either all sites commit or none of them does.
The different distributed commit protocols are −
One-phase commit
Two-phase commit
Three-phase commit
Distributed One-phase Commit
Distributed one-phase commit is the simplest commit protocol. Let us
consider that there is a controlling site and a number of slave sites where the
transaction is being executed. The steps in distributed commit are −
After each slave has locally completed its transaction, it sends a
“DONE” message to the controlling site.
The slaves wait for “Commit” or “Abort” message from the controlling
site. This waiting time is called window of vulnerability.
When the controlling site receives “DONE” message from each slave, it
makes a decision to commit or abort. This is called the commit point.
Then, it sends this message to all the slaves.
On receiving this message, a slave either commits or aborts and then
sends an acknowledgement message to the controlling site.
Distributed Two-phase Commit
Distributed two-phase commit reduces the vulnerability of one-phase commit
protocols. The steps performed in the two phases are as follows −
Phase 1: Prepare Phase
After each slave has locally completed its transaction, it sends a
“DONE” message to the controlling site. When the controlling site has
received “DONE” message from all slaves, it sends a “Prepare”
message to the slaves.
The slaves vote on whether they still want to commit or not. If a slave
wants to commit, it sends a “Ready” message.
A slave that does not want to commit sends a “Not Ready” message.
This may happen when the slave has conflicting concurrent
transactions or there is a timeout.
Phase 2: Commit/Abort Phase
After the controlling site has received “Ready” message from all the
slaves −
o The controlling site sends a “Global Commit” message to the
slaves.
o The slaves apply the transaction and send a “Commit ACK”
message to the controlling site.
o When the controlling site receives “Commit ACK” message from
all the slaves, it considers the transaction as committed.
After the controlling site has received the first “Not Ready” message
from any slave −
o The controlling site sends a “Global Abort” message to the
slaves.
o The slaves abort the transaction and send a “Abort ACK”
message to the controlling site.
o When the controlling site receives “Abort ACK” message from all
the slaves, it considers the transaction as aborted.
Distributed Three-phase Commit
The steps in distributed three-phase commit are as follows −
Phase 1: Prepare Phase
The steps are same as in distributed two-phase commit.
Phase 2: Prepare to Commit Phase
The controlling site issues an “Enter Prepared State” broadcast
message.
The slave sites vote “OK” in response.
Phase 3: Commit / Abort Phase
The steps are same as two-phase commit except that “Commit ACK”/”Abort
ACK” message is not required.
