Two-phase commit and the Saga pattern provide similar solutions in a certain sense. Two-phase commit by Atomikos provides additional benefits compared to Sagas, and so does TCC. See the table below for details as to how Atomikos compares to Sagas, as well as what TCC can do…
Feature | Benefit | Atomikos XA / 2-phase commit | Atomikos TCC | Saga pattern | Remarks |
---|---|---|---|---|---|
NO "single point of failure" (SPOF) | Can we avoid a critical bottleneck node? | Nodes can be clustered for resilience. | |||
Heterogeneous systems supported | Can we integrate .Net and Java, and polyglot persistence? | TCC and Saga support any backend or service that complies to the API contract. For TCC there is a published API contract, for Sagas the situation is less clear. Atomikos XA only supports Java systems and (primarily) XA backends. | |||
Automatic "rollback" after timeout / HTTP errors | Increased reliability at a much lower cost | If HTTP requests time out, there is uncertainty at the calling end about whether the remote committed any changes, or none at all. This can lead to either orphaned, duplicate or lost updates. | |||
Avoidance of dirty reads | Correct reporting and read operations | Sagas can be compensated later, but intermediate reads are allowed. This is like dirty reads in the database at the SQL level and usually a big turn-off for most systems. | |||
Pre-tested transaction logic | Increased reliability at a lower cost | Is the transaction logic tested by a vendor implementation? | |||
Commercial support available | Fast solution for problems | Can you get fast expert assistance if things break? | |||
XA drivers available? | Automatic rollback support by DBMS or broker | You have to implement the rollback logic yourself, it's more expensive and (in case of Sagas) allows dirty reads. | |||
Automatic handling of undo failure | Increased simplicity and reliability at an even lower cost | Non-XA solutions require custom coding without a clear API description and suffer from idempotent consumer pitfalls. |
We implemented XA / two-phase commit for microservices - not because we wanted to, but because our customers did not like the cost of developing compensation logic for their APIs: it is too much overhead and too hard to test (at least for microservice components within one company). After the WS-* failure we did not believe in any kind of transaction remoting mechanism any more, but changed our minds due to popular demand in our community. Now we have something simpler that just works, without extra coding or testing overhead.
Sagas were invented for centralised DBMS solutions 30 years ago. They were never really designed for microservices and distribution because they can't cope well with communication failures / timeouts: while they may increase "availability", they do so by allowing dirty reads in between a service invocation and its compensation / undo. So you are never really sure of whether your reads are correct or not, the value you read may still be compensated for later.
So what do you do? It's simple:
In one word: marketing. The western world has been hearing about Sagas because "two phase commit is unavailable for microservices". That's understandable, because the gurus and platform vendors who were spreading this message simply lacked access to the right technology. Not any more (we offer it). By the way, TCC is really popular in China, where they have different channels and less influence from the West.
Download our free / open source product and see how you can solve your microservice transaction problems with Atomikos. Click the button below to get it directly in your inbox!
Our privacy policy is brief and clear: we do not sell the information you give us. Plus, we'll send you relevant content (only). Our hosting platform is technically dependent on cookies so we can't realistically offer you a no-cookie experience. By continuing your visit, you are assumed to agree with this fact.