[erlang-questions] Dealing with "transient" external service (database)

Jesper Louis Andersen jesper.louis.andersen@REDACTED
Mon May 13 17:49:27 CEST 2013


Also, in addition:

* While you are in the connecting state on your pool, you can return an error to that extent.
* See the DB as a service in a separate application. It tries hard to provide the service, but if something is amiss, it should report back that your query cannot complete due to DB connectivity. This way, the application programmer in CB can handle the error gracefully if possible.

Jesper Louis Andersen
  Erlang Solutions Ltd., Copenhagen



On May 13, 2013, at 1:11 PM, Loïc Hoguin <essen@REDACTED> wrote:

> Take a look at what I did here:
> 
>  https://github.com/extend/bank/blob/master/src/bank_worker.erl
> 
> Basically on startup a message is sent to itself to attempt connecting, then if that fails it sends another message N seconds later to retry. It retries until it finally connects, even if it takes days.
> 
> Once it has connected if something goes wrong the process crashes and the supervisor restarts it, going back to the first step above.
> 
> If a query is sent and the process crashes then an error is returned instead of the expecting value which can be handled as you wish.
> 
> On 05/13/2013 11:43 AM, David Welton wrote:
>> Hi,
>> 
>> I'm thinking about what needs to be done for this Chicago Boss feature
>> request/improvement:
>> 
>> https://github.com/evanmiller/ChicagoBoss/issues/254
>> 
>> With the key point being that CB should start even if the database is not up.
>> 
>> It should also handle someone stopping the database and having it be
>> down for a few minutes.
>> 
>> I'm trying to think of how this should work in Erlang, as I'm not sure
>> it fits into the supervisor model.  What I want to happen (I think) is
>> something along these lines:
>> 
>> * boss_db, which handles db connections, starts up, and tries to
>> connect to the db driver/database itself.
>> 
>> * If it can't connect, it sets some kind of flag, and keeps trying at
>> intervals (possibly with exponential backoff until it hits a certain
>> maximum interval).
>> 
>> * Something similar happens if the connection goes down because the
>> database has been stopped for whatever reason.
>> 
>> * Attempts to use boss_db when things are not ok generate some kind of
>> specific error that can be dealt with in other parts of the system, in
>> order to at least inform the end user that there is something unusual
>> going on, in a nice way.
>> 
>> Sorry if this is all a bit fuzzy, but I think the general idea is
>> clear: a web site should continue to run, but give warnings that can
>> be defined by the user when the DB is down, rather than crash
>> completely.
>> 
>> --
>> David N. Welton
>> 
>> http://www.dedasys.com/
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>> 
> 
> 
> -- 
> Loïc Hoguin
> Erlang Cowboy
> Nine Nines
> http://ninenines.eu
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions




More information about the erlang-questions mailing list