views:

171

answers:

2

What's a good way to persist state when restarting a crashed process?

I have a supervisor in an OTP application what watches several "subsystem" gen_servers.

For example, one is a "weather" subsystem that generates a new weather state every 15 minutes and handles queries for the current state of the weather. (Think the lemonade stand game)

If that gen_server crashes, I want it to be restarted, but it should be be restarted with the most recent weather state, not some arbitrary state hardcoded in init(). It wouldn't make sense for the simulation state to suddenly go from "hail storm" to "pleasant and breezy" just because of the crash.

I hesitate to use mnesia or ETS to store the state after every update because of the added complexity; is there an easier way?

+1  A: 

As long as it just has to be during runtime a would suggest the usage of ETS. The value is by far greater than the complexity. The API is simple and if you're working with named tables the access is simple too. You only have to create the table before your gen_server is started by the supervisor.

Two - more complex - alternatives:

  • Build a pair of processes, one for the job to do, one for the state maintenance. Due to the simplicity of the second one it would be really reliable.
  • A real silly one could be the exchange of the child spec of the supervisor with the current state as argument each time the state is changing. (smile) No, just kidding.
Mue
+1  A: 

is there an easier way?

when process died it sends message to supervisor that containing State of process, so you can use this value to store in supervisor (in mnesia or supervisor's state) and when your server will start (in init) it have to send sync call to supervisor to get State value. I haven't real example, but i hope it makes sense.

Anyway i don't really see problem to store State in mnesia.

sorry my English :)

JLarky