Distributed transactions and queues, ruby, erlang

Posted by chrispanda on Programmers See other posts from Programmers or by chrispanda
Published on 2011-10-13T07:13:15Z Indexed on 2011/11/14 2:04 UTC
Read the original article Hit count: 327

Filed under:
|
|

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 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? 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 - 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 its parallel processing capabilities, erlang is a better choice for implementing a blocking protocol like two phase commit, or am I confused?

© Programmers or respective owner

Related posts about ruby

Related posts about erlang