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

[Ken Ellis]

Amen, the whole dirty_* set of functions should be ripped out of the release.


On Sun, Mar 6, 2011 at 11:28 AM, Dan Gudmundsson <dgud@REDACTED> wrote:
> 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.
>
> /Dan
>
> On Sun, Mar 6, 2011 at 5:12 PM, Ken Ellis <kaellis@REDACTED> 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
>> 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
>>>
>>>
>>>
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>>
>