[erlang-questions] Ordering of mnesia events

[jensli@REDACTED]

Ok. Great to have that sorted out.

There are one last case that I can think of that could be of interest:

If you have two transactions:

Trans1 = fun() -> ... end,
Trans2 = fun() -> ... end,

mnesia:transaction(Trans1),
mnesia:transaction(Trans2),

Can subscribers be sure to get all the events that are caused by Trans1
before any of the events from Trans2? On all nodes?

I mean under the current implementation, not that it is documented behaviour.

>But as it not is explicitly stated in the documentation

Maybe it would be relevant for OTP to state that there are no guarantees
about the ordering of events in the documentation?


Thanks for your help!

/Jens Lideström

> 2010/12/8  <jensli@REDACTED>:
>> Thanks for your answer.
>>
>> Ok, so when operations happen in a transactions we cant be sure about
>> much, only that all the operations in the transaction are considered to
>> happen at once with no defined order, and we can only expect events that
>> reflect the final result of the transaction.
>>
>> But what about dirty operations?
>>
>> Same table:
>> mnesia:dirty_delete(tab1, SomeRec),
>> mnesia:dirty_write(tab1, SomeOtherRec)
>>
>> Different tables:
>> mnesia:dirty_write(tab1, SomeRec),
>> mnesia:dirty_write(tab2, SomeOtherRec),
>>
>> Obviously, they will happen in a defined order. But does that also hold
>> for the events?
>
> If it is the same process that performs all these dirty calls and the
> involved
> tables resides on the local node, the events will be delivered in the same
> order as they are performed to subscribers on the local node. This is the
> current behavior and it is very unlikely to be changed. But as it not is
> explicitly stated in the documentation you should not rely on the current
> behavior.
>
>> On all nodes?
>
> There is no global ordering in the sense that event #1 will be delivered
> to subscribers on all nodes before event #2 is delivered. But the events
> will occur in the same order on all nodes which have a replica of the
> table if it is the dirty updates originates from the same process. But
> as this is not documented...
>
> /Håkan
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>