<div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
runtest(N) -><br>
    mnesia:sync_transaction(<br>
        fun () -> mnesia:write(testtab, #testrec{id = N}, write) end),<br>
    mnesia:sync_transaction(fun () -> mnesia:delete({testtab, N}) end),<br>
    runtest(N-1).<br><br></blockquote><div><br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div>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:</div><div>
<br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<span class="Apple-style-span" style="font-family: Verdana, Arial, Helvetica, sans-serif; background-color: rgb(255, 255, 255); font-size: medium; ">This function waits until data have been committed and logged to disk (if disk is used) on every involved node before it returns</span></blockquote>
<div><br></div><div>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.<br>
<br></div><div>Sincerely,</div><div><br></div><div>jw</div><div><br></div></div><br>