[erlang-questions] A new backend for Mnesia

[Ulf Wiger (TN/EAB)]

Joel Reymont wrote:
> 
> I would like to write a new backend for
> Mnesia, for a centralized hashtable-like
> high-latency store that does not support
> transactions or locking.
> I'm not at liberty to disclose more.

This is non-trivial, but I guess you figured as much.

There is support for plugging in alternative backends
in the RDBMS contrib (you need to contact me to negotiate
a stable last version of rdbms - I haven't worked on it 
for quite a while), but you can view the external copy
support in the jungerl version. See e.g. the rdbms_rofs.erl
module (read-only file system) and rdbms_log (disk log plugin)

The main patches are in mnesia_tm, mnesia_schema and 
mnesia_lib. The low-level access "interface" used by mnesia
to commit data is in mnesia_lib.

Doing it this way is of course a bit limiting, but at 
least it's reasonably straightforward. Note that there
is no error handling at this level. If the low-level
access functions crash, mnesia dumps core.


> I figure it would be easier to piggyback on Mnesia than try 
> to roll transactions and locking of my own. I'm thinking of 
> creating a new table type for Mnesia and I know this has been 
> done before for BDB.
> 
> I have two questions:
> 
> 1) How easy would it be to make Mnesia only push the
> data to the backend store on the Mnesia node that received
> the write request?

That should be easy - just make sure that only that node
has a copy of the table.

> This would be akin to designating the rest of the nodes as 
> ram-only, I guess, except at write time.

Mnesia has no caching function, but you can access that 
table from anywhere within the cluster, due to mnesia's
distribution transparency.

> 
> 2) Where in the Mnesia code should I look to make it happen?
> 
> 3) Is Mnesia actually a good fit for such a project?

Well, quite some assembly required, so it depends on what 
your options are. At least, the code is available. (:

BR,
Ulf W