[erlang-questions] Is it safe to unlink from gen_fsm on the fly?
Tue Sep 22 20:34:53 CEST 2009
> I think it's possible to pass the connection in an (almost) safe
> manner having at any time at least one process from the supervision
> tree linked to the driver.
If you have the reconnection process always running, do you need to
spawn it and pass it around?
> There are three functional process: gen_server which is where
> SQL-requests are sent to, connector and epgsql driver. Here is
> (working but ugly) algorithm showing how to transfer the connection
> from the connector to the gen_server in such a way:
> 1. spawn_link connector process from gen_server
> 2. Do epgsql:connect() in connector
> 3. Send the connection from connector to gen_server
> 4. Link gen_server to the connection
> 5. Let connector know that gen_server is succesfully linked to the
> 6. Unlink connector from the driver and stop it
> The only thing I don't like about it except for complexity is that
> there may be some problems if PostgreSQL will crash between say 4 and
> 5 steps.
The real danger isn't between 4 and 5 (i.e. what if we're waiting for
the unlink request and it never comes). The real danger is everywhere
from 4 to 6, since a crash in the remote server will kill the linked
process, which will kill our gen_server. Since they're all linked,
the whole thing can go off like a bomb.
> Having the reconnection process always running is a brilliant idea
> that I missed while thinking about the problem! Thanks a lot for
> pointing it out!
> There is no need in sending async messages 'reconnect' from
> gen_server, because connector is always able to detect problems by
> itself (by catching exit signals coming from the epgsql driver) and
> send the connection to the gen_server asynchronously.
That said, you might be able to invert the scenario. What if it was a
gen_event? They you could just throw off a synchronous event when you
have a disconnection, and it could catch it to reconnect.
This also has the advantage that it neatly packages into the
application, as it's just a simple addition to the top_level supervisor.
More information about the erlang-questions