[erlang-questions] non-atomic nature of mnesia:dirty_update_counter

[Ken Ellis]

Hi Ulf,

Thanks for the clarification.  I also went back to that User Guide and
it does an admirable job of defining atomic as meaning the ACID
all-or-nothing variety and not what for example you'd call atomic when
incrementing counters within the linux kernel.  My bad, forgot I was
dealing with a database.  So I think in that sense the
dirty_update_counter is atomic across all nodes.  I guess the question
is when the users guide says atomicity is lost with dirty operations,
what exactly is non-atomic about dirty_write or any dirty operation
given that "Mnesia also ensures that all replicas of a table are
updated if a dirty write operation is [successfully?] performed on a
[any?] table".  Isn't that the definition of all-or-nothing atomicity?
 Unless that statement is inaccurate, that would seem to mean all
dirty_* operations are atomic, and that dirty is a reference to what
an RDBMAS would call dirty reads, with an additional qualification
that it can break isolation of transactions.  Which by the way means
there is no isolation guarantee for any transaction, since dirty
operations compromise their isolation.  (IMaybe filthy_* would be a
better prefix :).  But I suppose for now I'll take the statement about
lack of atomicity as true, and that dirty writes can be only partially
executed and can leave tables on different nodes in an inconsistent
state.

Ken


On Sun, Mar 6, 2011 at 2:19 AM, Ulf Wiger
<ulf.wiger@REDACTED> wrote:
>
> On 6 Mar 2011, at 06:54, Ken Ellis wrote:
>
> After running test_counter:run(5000,1) on each node simultaneously,
> and comparing the files, i get 2893 duplicates out of 5000.  Although
> the counter has been incremented by 10000.  I can't repro running on a
> single node with a large number of processes, so it seems atomic in
> that case.
>
> It is exactly the single-node case that is atomic. The documentation should
> spell this out.
> The User Guide does say that you lose mnesia's atomicity and isolation
> properties if you use dirty operations, which does seem to contradict what
> is said about dirty_update_counter(), but what the Reference Manual (*and*
> User Guide) should say is that dirty_update_counter() is atomic only in a
> very limited context.
> The User Guide does say something else that is, strictly speaking, wrong:
> "It is not possible to have transaction protected updates of counter
> records."
> It is of course possible - they are only records after all. You can do an
> update counter inside a transaction through a combination of read() and
> write().
> BR,
> Ulf W
> Ulf Wiger, CTO, Erlang Solutions, Ltd.
> http://erlang-solutions.com
>
>
>