first, I consider Akka's Agents/Transactors "just" as a very well-thought wrapper around Scala STM, that's why I'm asking this questions here. I'm a little bit unsure about what happens when running a distributed transaction with Akka, which internally makes use of the CommitBarrier (right?!). Here's the scenario: A distributed system with various nodes, each maintaining it's own state. At some point, state on multiple nodes must be changed atomically, or, alternatively, in two stages with acking. So, there is Scala STM and Akka support for it.. awesome, let's use it to run a distributed transaction instead of using the two stage process. Questions:
- Assuming the distributed transaction commits, what's visible to concurrent readers of each node's state? For example, two nodes A and B participate in a successful (committing) distributed transaction. Some actor on node A reads A's new state (after commit) and sends a message to B according to A's new state, could some actor on node B read B's old state when handling this message? It really is about possible race conditions. For example, commit sent to A and B, A commits, A sends message to B based on new state, B did not yet receive commit but receives message from A.
- Assuming the distributed transaction commits, what happens in the case of node failure? For example, state changes should be persisted to some database using an afterCommit handler. What happens if the commit is sent to two nodes A and B, A commits and persists, but B crashes after committing but before executing the afterCommit handler. I guess the docs already answer this (lost state change), just want to make sure I did understand everything correctly.