Recently I've been working on a RESTful web app project in Erlang using Yaws appmods. I decided I needed a memory cache to cache a (MySQL) database table that is read often but updated infrequently. As an Erlang beginner, I decided to use Mnesia to see how it would go. Using Joe Armstrong's book Programming Erlang as a reference, I dove in and found Mnesia to be very intuitive and pretty easy to set up. I had my memory cache working pretty quickly.
Soon after, I decided I wanted to cache another table as well, but thought I'd try to do it using an ETS table instead of Mnesia just to become familiar with ETS. Long story short, I found it to be very frustrating. Once I got it working, I found that the ETS table would seem to randomly disappear. I then realized that running under Yaws the process that created the ETS table sometimes died at which point the table would be deallocated and no other process could read it.
The solution was going to be to create a separate process to manage the ETS table and all other processes would have to communicate with this process to get at any data in the table. Not a terribly difficult task, but why reinvent the wheel? Mnesia most likely already does something similar.
Moral of the story: Skip ETS and just use Mnesia.
Subscribe to:
Post Comments (Atom)
3 comments:
you know mnesia is just a frontend to ets/dets right?
If he didn't, what else would have been the point of the blog?
hint: "[...]why reinvent the wheel?"
hm, it is very interesting...
if mnesia is frontend of ets then I run
> erlang:memory(ets).
6912628808
so it is sum of mnesia used memory and other ets tables?
so, why
> lists:sum([ets:info(X, memory) || X <- ets:all()]).
864116853
give other result (on the same node)?
and why
> lists:sum([mnesia:table_info(X, memory) || X <- mnesia:system_info(tables)]).
1443675188
give another result?
Post a Comment