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

[Bob Ippolito]

Well, I'm sure you do know what you're doing in general, but not with
Mnesia. Mnesia is quirky. You will probably eventually regret using
Mnesia. We try and avoid it as much as possible, because of its
inability to do the right thing with network partitions and the dets
limitations for disk tables. If you can afford to, I'd look at using
something else instead.

On Sun, Mar 6, 2011 at 9:54 AM, Ken Ellis <kaellis@REDACTED> wrote:
> Yeah but to be blunt, that's two responses with "if you know what
> you're doing".  I know what I'm doing, I just have no idea what Mnesia
> is doing.  The documentation is inconsistent with itself and with
> Gudmundsson's remarks.  Perhaps switch it off for any table spread
> across multiple nodes if no guarantees can be made in that case?
>
>
> On Sun, Mar 6, 2011 at 12:07 PM, Bob Ippolito <bob@REDACTED> wrote:
>> Well, they're actually quite useful (for performance) if you know what
>> you're doing and the application can tolerate it. Often times the
>> return value of a counter is not important. I suppose if they were
>> ripped out, maybe fewer people would use Mnesia, which might be a net
>> good :)
>>
>> On Sun, Mar 6, 2011 at 9:00 AM, Ken Ellis <kaellis@REDACTED> wrote:
>>> 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
>>>>>
>>>>>
>>>>
>>>
>>> ________________________________________________________________
>>> erlang-questions (at) erlang.org mailing list.
>>> See http://www.erlang.org/faq.html
>>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>>
>>>
>>
>