Got the question from the friend.
"In my opinion the majority of people understand what 2PC (two-phase commit protocol) is and just how for doing things in Java or the majority of modern languages. Essentially, it's accustomed to make certain the transactions have been in sync if you have two or more DBs. Assume I have two DBs, A and B using 2PC in 2 different locations. Before A and B will be ready to commit a transaction, both DBs will report on their behavior towards the transaction manager and saying they will be ready to commit. So, once the transaction manager is acknowledged, it'll send an indication to A and B letting them know proceed. Here's my question.... Let us say A received the signal and commit the transaction. (things are completed)... B is going to perform the same but someone unplug the energy cable make the whole server shutdown. When B has returned online, what B is going to do? and just how B get it done? Remember, A is committed but B isn't, and that we are utilizing 2PC. (So, the style of 2PC reduces, is not it? :-) "
Two phase commit doesn't guarantee that the distributed transaction can't fail, however it does guarantee it can't fail quietly with no TM being conscious of it.
To ensure that B to report the transaction to be prepared to commit, B should have the transaction in persistent storage (i.e. B must have the ability to guarantee the transaction can commit in most conditions). In cases like this, B has endured the transaction however the transaction manager has not received a note from B verifying that B has completed the commit.
The transaction manager will poll B again when B returns on the internet and request it to commit the transaction. If B has committed the transaction it'll report the transaction as committed. If B has not committed the transaction it'll then commit because it has endured it and it is thus still capable of commit the transaction.
To ensure that B to fail in cases like this, it would need to undergo a catastrophic failure that lost data or log records. The transaction manager would still remember that B hadn't reported a effective commit.1
Used, if B can no more commit the transaction, it might signify the disaster that required B out had triggered loss of data, and B would benefit by an error once the TM requested it to commit a TxID it wasn't conscious of or did not think is at a commitable condition.
Thus, two phase commit doesn't prevent a catastrophic failure from happening, however it does avoid the failure from going undetected. Within this scenario the transaction manager will benefit by an error to the applying if B cannot commit.
The applying still needs to have the ability to get over the mistake, however the transaction cannot fail quietly with no application being made conscious of the sporadic condition.
- Observe that this kind of failure may also lose data from formerly committed transactions. Two phase commit doesn't guarantee the resource managers can't lose or corrupt data or that DR methods don't ruin.