[erlang-questions] Ordering of mnesia events
Thu Dec 9 13:53:54 CET 2010
The transaction can happen in parallel if they access different objects,
so there is no order guarantee.
> 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,
> 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
>> 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
>>> 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...
>> 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
More information about the erlang-questions