[erlang-questions] Misbehaving ets table in a gen_fsm

Ivan Uemlianin ivan@REDACTED
Fri Oct 11 14:36:55 CEST 2013

Dear All

I am maintaining some code the original author of which has long gone. 
A gen_fsm has a state variable which is a key/value structure with 
integer keys.  I might use a dict for this, or an array; the author uses 
an ets table.

 From some error reports, it looks like this ets table occasionally 
"mislays" its keys.  Perhaps empties or renews itself silently.

Finally, in the event of a crash/restart, the data in this ets variable 
should be preserved and passed on the new gen_fsm process.  However, the 
gen_fsm module has nothing special to handle this in its terminate/3, 
and init just creates a new table.

This is all a bit mysterious so I'm going to write a gen_fsm that has 
nothing but the above, try and replicate the "mislaying" and generally 
get it behaving properly.

I have three questions:

1. I can't think of any good reason to use an ets table over a dict or 
an array, other than sharing the data structure with other processes, 
which isn't done.  There are several inconclusive debates on the web 
about which is fastest.  Is there a reason I'm missing for why an ets 
table might be most appropriate?

2. Under what circumstances if any can an ets table mislay keys?  At 
some point the table stops recognising keys it should know about.  There 
are no other errors in the system.

3. Persisting data across crash & restart I might store the data in the 
fsm's terminate/3 (if it was a non-normal termination), and check for 
the stored data in the fsm's init/1.  Is that a common approach?  has 
any approach co-allesced into a "pattern" or are types of storage, kinds 
of data, etc too variable?  Might keeping the data in an ets table the 
whole time remove the need for this step?

With thanks and best wishes


Ivan A. Uemlianin PhD
Speech Technology Research and Development


                         festina lente

More information about the erlang-questions mailing list