mnesia table type: ephemeral
Sat Dec 18 14:23:29 CET 2010
Some ideas tend to stick in an annoying way until you can either
dismiss them or implement them…
Some weeks ago, I started thinking that it would be very handy to
have an "ephemeral" table type. For those who are unfamiliar with the
term, "ephemeral" means "passing" or "lasting only a very short time"*.
It would actually be quite easy to implement, and if nothing else, it
would be perfectly in line with mnesia's "amnesia" origins. :)
An ephemeral table would work like this:
- It has no content that survives transactions
- You can write to it within a transaction, and read back what is
in the transaction store.
- When committed, the data written gets replicated to all copy holders
(but is not kept)
- You can subscribe to table events just like on normal tables.
The main purpose of an ephemeral table would be to commit derived
and perhaps complex data which can be reported to outside observers
via the mnesia subscription algorithm. Basically, you can sculpt the
commit message without regard to what your persistent data structure
needs to look like. Also, if your transaction results in multiple updates,
you can combine them in one record in the ephemeral table, making it
much easier for subscribers to get the full picture.
One could even use this as a generic publish-subscribe mechanism,
and it should be fine simply doing a dirty write in order to propagate the
The original problem that triggered the idea was creating files from within
mnesia transactions, and keeping the files synchronised on multiple disks.
I'm not entirely convinced that this alone can solve that problem, but perhaps
together with a transaction log hooked into the subscription mechanism, one
can get quite far.
Comments are welcome. I've not started implementing it yet.
Ulf Wiger, CTO, Erlang Solutions, Ltd.
More information about the erlang-questions