Two-phase commit for distributed transactions: what if a commit failed?
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.