Evaluation Summary: Fault Tolerance
The following table shows the results for the criteria defined in Criteria Catalog: Fault Tolerance.
| Execution timeouts | enforced | enforced | ✔ | |
| Reaction to participant fault | unsubscribe | retry | retry | developer's responsibility & compensation |
| Saga continuation trigger after orchestrator crash | new Saga instance | restart of Conductor server | restart of TravelService | (developer's responsibility) |
| New Sagas while orchestrator unavailable | ✔ | only with buffering | ||
| Independent compensating transactions | ✔ | ✔ | ✔ | |
| Orchestrator reaction to duplicate messages | detect & ignore | detect & ignore | log exception & ignore | developer's responsibility, detect & ignore |
| Orchestrator reaction to old messages | detect & ignore | detect & ignore | log exception & ignore | eveloper's responsibility, detect & ignore |
| High availability | through replication | through replication | through replication | – |
Info
The MicroProfile LRA specification does not include explicit information on whether it is possible to achieve high availability through methods like replication. Furthermore, the chosen runtime OpenLiberty, which includes the implementation for LRA, is still in a beta state1. Therefore, their official documentation does not include information about MicroProfile LRA yet, which also means no information about a highly available system with it. Consequently, further tests would be necessary to be able to make a statement about high availability with MicroProfile LRA.
-
https://openliberty.io/blog/2021/01/27/microprofile-long-running-actions-beta.html, last accessed: 2021-07-15 ↩