4 ms·
A long, long time ago we used to have two-phase commit protocols and XA. I am afraid most of sagas are 2PC in disguise - just requiring a programmer to explicit
by mkleczek 3y ago
A long, long time ago we used to have two-phase commit protocols and XA.
I am afraid most of sagas are 2PC in disguise - just requiring a programmer to explicitly implement rollbacks.
The situation is similar to the whole "database inside out" hype that drives application programmers to re-implement proper DBMS.
I am pretty sure the IT hype wheel will turn around and someone will sell 2PC as a new shiny thing.
- lorendsr 3y ago2PC tends to have limited throughput due to the participants needing to hold a lock between the voting and commit phase, and all the participants need to support the protocol. Sagas work across different services and data stores and can have high throughput. However, if all of the data you need to update is in a single database that supports atomic commits, I'd go with that over sagas.
- mkleczek 3y ago> 2PC tends to have limited throughput due to the participants needing to hold a lock between the voting and commit phase Scalability depends on lock granularity, what's more... > Sagas [...] can have high throughput There is no real difference as sagas in practice implement locking in disguise - take the scenario of flight/hotel/car booking: Once you book a hotel - this particular resource (a room at a particular time) is effectively locked. Cancelling the booking (because other participants failed in saga) is effectively releasing the lock. The room (resource) is locked for the duration of the whole process anyway (as no other customer can book it during this time). The downside of sagas is that a programmer is forced to explicitly handle all failure scenarios - which costs development time, is error-prone etc.