[erlang-questions] Considering a Generic Transaction System in Erlang
Fri Oct 23 22:40:19 CEST 2015
On 23.10.2015 17:06, Torben Hoffmann wrote:
> 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.
I like your design. It's not that you poll every nanosecond and since
you spawn the function the sending process can just continue work.
I guess I'm still too much stuck in the OO way of thinking. The fact
that you can just spawn any function in a fire-and-forget manner didn't
come to my mind (although I remember having seen it in the textbooks).
Your approach is simple and doesn't need an extra service. Neat.
> 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