[erlang-questions] non-atomic nature of mnesia:dirty_update_counter
Sun Mar 6 17:28:13 CET 2011
Nothing is promised with dirty_write don't use it.
Dirty read may be ok if you know what you are doing
but avoid dirty_write in multiple node system.
On Sun, Mar 6, 2011 at 5:12 PM, Ken Ellis <> wrote:
> 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
> On Sun, Mar 6, 2011 at 2:19 AM, Ulf Wiger
> <> 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
>> 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
>> Ulf W
>> Ulf Wiger, CTO, Erlang Solutions, Ltd.
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:
More information about the erlang-questions