[erlang-questions] mnesia sync_transactions not fsynced?

[Jon Watte]

> runtest(N) ->
>    mnesia:sync_transaction(
>        fun () -> mnesia:write(testtab, #testrec{id = N}, write) end),
>    mnesia:sync_transaction(fun () -> mnesia:delete({testtab, N}) end),
>    runtest(N-1).
>
>

This code runs two separate transactions.  One to add a record, and one to
delete a record. If you bring down the node after the first one has
committed, but before the second one has committed, then you will see one
record when you start up again.

Are you claiming that if you run this from 100 through 0, and crash the node
at 10, you may see a record with the value 40 in the database? If that is
the case, then the cause is simply that all of the transactions from 39 .. 0
never wrote to disk before the crash. This can, roughly, be thought of as a
SQL database achieving some particular point in its binlogs, but nothing
beyond that point.

The observation here is that mnesia:sync_transaction(), under the conditions
observed, does not fulfill the "Durable" part of ACID transactions -- a
committed transaction (writing value 39, say) was observed by the system,
but after re-start, that point was not durable.
Whether mnesia:sync_transaction() "should be" durable is not something I'm
qualified to answer :-) However, reading the documentation, it certainly
*sounds* as if it should provide durability:

This function waits until data have been committed and logged to disk (if
> disk is used) on every involved node before it returns


Thus, assuming that you don't have a kernel/device-based write
cache/power-fail outage (but simply an Erlang process death outage), then I
would expect the last record seen on disk to be the last record observed in
the test function.

Sincerely,

jw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20111027/a26c3cd2/attachment.htm>