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