[erlang-questions] Using ram-only mnesia in place of gen_server+ets table

[Shayan Pooya]

Hello Ludovic,

I was more curious about the best practices of 'shipping' the dbs to the
slaves. Creating the table, marking it as read-only and then shipping it to
the slave nodes makes sense but it seems like it is not possible and we
have to set the hosting nodes of a table at its creation time.

Thanks.


On Thu, Jul 17, 2014 at 5:21 PM, Ludovic Demblans <ludovic@REDACTED>
wrote:

> Hi,
>
> If you plan to use dirty read-only acces, (and if this is the only
> problem), any process can acces the table data if it is in 'protected' mode
> (which is the default.
>
> Cheers
>
> lud
>
> Le Thu, 17 Jul 2014 22:42:48 +0200, Shayan Pooya <shayan@REDACTED> a
> écrit:
>
>
>  Disco filesystem gc involves a step in which a process builds an ets table
>> on the master and
>> the slave nodes query this ets table regularly afterwards.
>> The ets table is owned by a gen_server which responds to the queries from
>> the
>> slaves using this ets table.
>>
>> I am experimenting with using a mnesia table instead of this ets table so
>> that
>> the gen_server is not involved in this operation (There are a lot of
>> queries and
>> this master process is a bottleneck).
>> This is a ram-only mnesia table which is created and then made read-only.
>> All of
>> the operations use mnesia:dirty_* functions and the slave nodes never
>> modify the
>> table.
>>
>> 1. Is this going to avoid the gen_server bottleneck?
>> 2. I am thinking of adding all of the nodes (master + slaves) as the
>> ram-copies for
>> this table in order to have local lookups on the slave nodes.
>> Is this going to slow down the creation of the mnesia table? (as
>> said before, it is only using dirty_* functions for modifying the table).
>>
>
>
> --
> Utilisant le logiciel de courrier révolutionnaire d'Opera :
> http://www.opera.com/mail/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140718/e93ef336/attachment.htm>