I have 2 servers participating in 2PC scenario:

* Srv1: votes OK
* Srv2: votes OK
* Coordinator runs "commit"
* Srv1: commits
* Srv2: does not accept "commit" command because of network failure

From this moment my distributed DB is not consistence anymore.

How it should be solved?

  • How to move it there?
    – user996142
    Oct 31, 2012 at 14:34
  • We must have 4 more votes to move it, or you can delete your question and re-ask there.
    – Kermit
    Oct 31, 2012 at 14:36
  • 1
    Why does this belong on dba.se? This is an algorithmic question as I understand it.
    – usr
    Oct 31, 2012 at 14:59

1 Answer 1


Server 2 is obliged by its duties under the 2PC to contact the coordinator for advice on the state of the transaction. Until it gets a Commit or Rollback from the coordinator, it must hold the transaction in the 'Ready to Commit' state, locks and all — even if it is restarted.

This could go on indefinitely, of course, so in practice there are 'Presumed Fail' or 'Presumed Succeed' heuristics that can be applied, but it is not something to undertake lightly. If you get into a heuristic operation, then you probably do have an inconsistent set of databases — which is just one reason not to go 'heuristic' in a hurry. Of course, if the Coordinator or the network are out of commission for any extended period of time, you probably have other problems than just database consistency.

You can find out a lot from reading Concurrency Control and Recovery in Database Systems by Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman (available for download). That is tough going, though. You could look in Date (Database Fundamentals, 8th Edn), but it is covered very briefly there, or Recovery Mechanisms in Database Systems by Kumar and Hsu, which has a substantial discussion of 2PC in chapter 13.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.