<div dir="ltr"><div>Mnesia transactions are restarted when something hinders the completion of</div><div>the transaction. Basically locks that are occupied or that another involved mnesia-node goes down during the transaction.</div><div><br></div><div>So in your single node case it it caused by locks conflicts.</div><div><br></div><div>To avoid deadlock and starvation mnesia locks are restarted if</div><div>the transaction id is newer than the transaction holding the lock.</div><div>Otherwise the transaction will be queued until that lock is released.</div><div><br></div><div><br></div><div><br></div><div><br></div><div>/Dan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 24, 2014 at 6:08 AM, Bernard Duggan <span dir="ltr"><<a href="mailto:bduggan@shoretel.com" target="_blank">bduggan@shoretel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi List,<br>
Can anyone shed some light for me on the exact circumstances under which<br>
mnesia transactions will restart? I ask because on our system (which I'd<br>
describe as "moderately loaded", on the order of maybe a few million<br>
transactions a day) we had a couple of cases recently where a relatively<br>
simple read-then-write transaction hit 60 retries and 82 seconds. This<br>
is a single-node system using a disc_copies table with a couple of extra<br>
indices set on it, but nothing else very special.<br>
<br>
Of course, mnesia did no less than what the manual promised: the<br>
transaction eventually completed. However I'd like to understand better<br>
what might lead to so many retries (and, as a result of the increasing<br>
retry backoff, the very long delay). I've read every bit of "mneisa<br>
internals" documentation I can get my hands on, but I'm still a bit<br>
hazy. If I read that stuff correctly, it seems that unless there's a lot<br>
of transactions that started *before* the one in question, and ran for a<br>
very long time themselves, it should actually have been queued up to run<br>
next rather than retrying. It seems very likely that there are other<br>
cases that will cause a retry regardless of how "old" the transaction is<br>
with respect to any it might conflict with (the manual casually mentions<br>
that it may be restarted "thousands" of times), but it's those cases<br>
that I'm not clear on.<br>
<br>
Cheers,<br>
<br>
Bernard<br>
<br>
______________________________<u></u>__<br>
<br>
This e-mail and any attachments are confidential. If it is not intended for you, please notify the sender, and please erase and ignore the contents.<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</blockquote></div><br></div>