Distributed transaction (w/ Akka)

[Felix-Johannes Jendrusch]

Hi,

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.

Best regards

Felix

[Nathan Bronson]

Felix,

You'll probably get a better answer on the Akka user mailing list. Akka's model starts with agents and adds STM support to address things not served well by the former, rather than the other way around.  I'll try to answer the STM parts as best I can:

Regardless of the number of threads, actors, or nodes involved, updating a database in afterCommit opens you up to losing the update. The JVM may be killed between commit and afterCommit, or there may be an arbitrary delay (I've seen a 15 minute stop-the-world GC for a box that was swapping due to another process's memory leak, after which the program woke up and continued). This can be solved either with a 2 phase DB commit (using whilePreparing to prepare the DB transaction and afterCommit to complete it) or by committing from an STM ExternalDecider (or a whileCommitting callback). The 2PC DB commit scales better, but requires additional work to figure out if dangling transactions should be rolled forward or backward after a crash. If you can tolerate it, by far the simplest, most performant, and most scalable solution is to tolerate the lost update.

ScalaSTM's CommitBarrier works only within a single JVM, so it doesn't have to deal with process crashes.

 - Nathan

Felix

--
 
---
You received this message because you are subscribed to the Google Groups "Scala STM Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-stm-expert-...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Nathan Grasso Bronson
ngbr...@gmail.com

[Felix-Johannes Jendrusch]

Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to scala-stm-expert-group+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.