[erlang-questions] Considering a Generic Transaction System in Erlang

Torben Hoffmann <>
Fri Oct 23 17:06:49 CEST 2015

Jörgen Brandt writes:

> Hey Torben,
> thanks for your reply.
> On 19.10.2015 10:51, Torben Hoffmann wrote:
>> Hi Jörgen,
>> With the risk of showing my inability to understand your problem I would challenge
>> the need for the transaction server altogether.
>> As you say, the messages that the processing server has yet to process will be lost
>> if the server dies, so re-sending is required.
>> I would simply deal with this in the client.
>> When you send a request you monitor the server, if it dies, you re-send when the
>> service is up again.
>> The server monitors clients, if the client dies, the server stops the pending and
>> ongoing jobs for that client.
> You are perfectly right. It would be advantageous to have a
> decentralized model for this. The reason I proposed a centralized
> architecture (with a dedicated transaction server) is the following:
> You send a request to a server. The server dies. Because of a monitor
> you find out you have to resend the message when the server is up again.
> So far so good.
> How do you find out, the server is up again? There will be a millisecond
> or something the supervisor needs to restart the server and you need to
> make sure, not to repeat the message into the void.
> How did you address this issue in your GOL implementation?
I'm dirty. I poll the egol_cell_mgr.

The proper way of doing it would be to add a
egol_cell_mgr:await_new_neighbour(N, OldPid)
function and then get a message back from egol_cell_mgr once a new process has been
Or make the the call synchronous - I'm spawning a function anyway to do the polling,
so it might as well just hang there until the process is there.

What is best depends on the problem.
For egol, I think the asynchronous approach is probably better as it follows the rest of the

Torben Hoffmann
Architect, basho.com
M: +45 25 14 05 38

More information about the erlang-questions mailing list