11

Recently I've read multiple times that two-phase commits are bad, but always as a side note. So there was never a good explanation with it.

For example in CQRS Journey Chapter 5:

Second, we're trying to avoid two-phase commits because they always cause problems in the long run.

Or in Implementing Domain-Driven Design on page 563:

The second ReadRecorts() is used by the infrastructure to replicate events, to publish them without the need for two-phase commit, ...

I thought two-phase commits are implemented to ensure consistency among multiple database servers.

What problems can occur when using two-phase commits? Why is it better to avoid them?

Domysee
  • 12,718
  • 10
  • 53
  • 84
  • 1
    See http://www.enterpriseintegrationpatterns.com/docs/IEEE_Software_Design_2PC.pdf – Matt Oct 09 '15 at 08:54

1 Answers1

13

The biggest problem is scalability due to the blocking nature of the 2 phase commit protocol.

2PC requires a careful coordination between the participating parties: In particular, each party has to acknowledge the prepare phase and the commit. Once a party has acknowledged that it is ready to commit, it has to block until the transaction coordinator sends the commit or rollback message. If either of the parties is over a network, the network latency causes a bottleneck for the communication between the nodes.

Furthermore, once a party has acknowledged that it is ready to commit, it must actually be able to commit the transaction afterwards even if it crashed inbetween. This requires checkpointing to persistence storage (even when the transaction is rolled back afterwards) and also possibly limits the throughput.

Alexander Langer
  • 2,883
  • 16
  • 18