mnesiaex (was mnesia ram cache)

Evans, Matthew <>
Thu Apr 22 22:46:47 CEST 2010


I was wondering if anyone had had any luck using mnesiaex

I am reasonably confident that I can get the required performance from plain old mnesia+DETS, but it seems that mnesiaex could be a good standby if I can not get the desired performance (perhaps using SleepyCat or similar as the backend).



-----Original Message-----
From:  [mailto:] On Behalf Of Evans, Matthew
Sent: Wednesday, April 21, 2010 6:41 PM
To: Bernard Duggan
Subject: RE: [erlang-questions] mnesia ram cache

Thanks for that, it's good to know.

In this case I should be fine since there should be no cases where a single transaction will make changes to > 1 table in a single transaction.

But in future your change will help for another project I am working on.

-----Original Message-----
From: Bernard Duggan [mailto:] 
Sent: Wednesday, April 21, 2010 6:30 PM
To: Evans, Matthew
Subject: Re: [erlang-questions] mnesia ram cache

Evans, Matthew wrote:
> To implement this I intend to write my own ETS cache on top of mnesia, and use table subscription to the mnesia table (mnesia:subscribe/1) so that the cache can be updated when inserts and updates occur to the master mnesia database. The cache shall be managed by a gen_server that contains LRU or similar rules to purge data to avoid it growing too much.
Something to be aware of before you get too attached to this plan: you
won't be able to maintain transactional atomicity in the cache.  That
is, if, for example, some node makes changes to two tables within a
single transaction, the subscription system as of R13B04 does not have a
nice way for a subscriber to group them together.  The result could be
that someone reading the cache may get one change but not the other. 
This may not matter for your case if any single write leaves your
database in a consistent (or "consistent enough") state, but it's
important to know that you'll be losing that feature of mnesia.  (There
is, however, a patch I wrote in R14 which addresses this exact limitation).



erlang-questions (at) mailing list.
To unsubscribe; mailto:

More information about the erlang-questions mailing list