I have a problem that involves several machines, message queues, and transactions. So for example a user clicks on a web page, the click sends a message to another machine which adds a payment to the user’s account. There may be many thousands of clicks per second. All aspects of the transaction should be fault tolerant.
I’ve never had to deal with anything like this before, but a bit of reading suggests this is a well known problem.
So to my questions. Am I correct in assuming that a secure way of doing this is with a two phase commit, but the protocol is blocking and so I won’t get the required performance? I usually write Ruby, but it appears that DBs like redis and message queuing system like Rescue, RabbitMQ etc don’t really help me a lot – even if I implement some sort of two phase commit, the data will be lost if redis crashes because it is essentially memory-only.
All of this has led me to look at erlang and scala – but before I wade in and start learning a new language, I would really like to understand better if this is worth the effort. Specifically, am I right in thinking that because of their parallel processing capabilities, these languages are a better choice for implementing a blocking protocol like two phase commit, or am I confused? And if yes, is there any reason to pick one rather than the other (specifically in this context – i know there are plenty of threads and blogs comparing the two more generally)
Apologies for cross posting – this was first posted to stack-exchange but I’ve added to the question and this version is probably a better fit here
1) 2 phase commit is not fault tolerant – see the link. You either need a total order broadcast, or a non-blocking atomic commit, depending on the exact formulation of the problem you’re solving.
2) I wouldn’t say that Scala is much more suited than most other general purpose languages for implementing a two-phase commit. Specifically, STMs, parallel and distributed collections will not help you here. Scala actors and remote actors may provide you with a nice API to send messages around asynchronously (on the same machine or remotely), but they do not by default give you abstractions such as different failure detectors which would be useful for implementing total order broadcasts, for example – you’ll still have to implement these yourself (on the other hand, I believe Akka has these abstractions).
3) I cannot speak for Erlang and Ruby, but as far as Scala and Java are concerned, you might want to consider taking a look at Akka. It is based on a distributed actor model, which also supports transactions and different levels of fault tolerance. It’s probably better to reuse their infrastructure than writing your own distributed fault tolerant runtime from scratch.