Inserting without overwriting with mnesia or ets

[Ulf Wiger]

On Sat, 08 May 2004 18:29:49 -0500, Hal Snyder <hal@REDACTED> wrote:


> Just to make sure I'm on the same page with you guys, let me rephrase
> things a little. Feel free to correct if I missed something.
>
> I guess the thread is about distributed atomic test-and-set. The
> "generic approach" below is needlessly slow if
>
> a. updates always happen on one node
> b. replicas are kept on other nodes for reliability only

Actually, the "generic approach" is needlessly slow unless one
has to account for the possibility of multiple processes
simultaneously performing the test-and-set operation, and there
is no practical way to serialize the operations using a server
(see below.)

A very simple and useful pattern in Erlang is to create a
test-and-set server, which serializes all accesses to the
resource in question. The server can then opt to use dirty operations
or ets, depending on storage criteria. In some cases, one may
still want to use transactions for their rollback semantics
(another aspect on atomicity), but in this particular case, that
doesn't add much benefit. This solution is very easy to understand,
and it is also quite fast.


> Next comes a question about mnesia and dirty ops, which I think is
> mostly answered by Ulf's previous reply: under what conditions is a
> sequence of dirty reads and writes from a single process to a mnesia
> table consistent, i.e. each read or write sees the table as if all
> previous updates have completed in order, if no other process writes
> to the table?

The sequence is consistent if no other process writes to the table,
and provided that the sequence runs to completion. (:

> The answer seems to be:
>
> a. table exists as ram_copy locally (+ .. ) as in next paragraph

No, whether it is ram, disc, or disc_only doesn't matter for dirty ops.
They will also honour indeces. Storage and location independence, as
well as replication support are basically what you gain from using
dirty ops instead of ets.


> b. remote tables too? Doesn't that get into questions of message ordering
>    as discussed recently on this list?

Dirty operations support remote tables; ets operations don't.
Not really, as long as the criterion that only one process is updating
the resource still holds.

/Uffe
-- 
Ulf Wiger