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

[Jörgen Brandt]

Hey Torben,

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
> registered.
> 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.
> (https://github.com/lehoff/egol/blob/testable/src/egol_cell.erl#L370)

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.

Cheers
Jörgen

> 
> What is best depends on the problem.
> For egol, I think the asynchronous approach is probably better as it follows the rest of the
> design.
> 
> Cheers,
> Torben
> --
> Torben Hoffmann
> Architect, basho.com
> M: +45 25 14 05 38
>