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

[bile@REDACTED]

Such as? There are lots of random DBs available but any with the ease
of use and speed mnesia seems to offer?

On Sun, 6 Mar 2011 10:01:24 -0800
Bob Ippolito <bob@REDACTED> wrote:

> 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
> >>>
> >>>
> >>
> >
> 
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>