<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF">
Thanks very much Dan. That was pretty much exactly my understanding, but it's very helpful have it confirmed. It really seems, in our case, like the starvation-avoidance system should have precluded such a high number of retries as we're seeing, particularly
when the write is only on a single record. But since it *is* happening there must be some property of our system that I don't fully understand. Time to go digging again :)<br>
<br>
Cheers,<br>
<br>
Bernard<br>
<br>
<div class="moz-cite-prefix">On 24/10/14 17:16, Dan Gudmundsson wrote:<br>
</div>
<blockquote type="cite">
<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>
________________________________<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>
_______________________________________________<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/listinfo/erlang-questions</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><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>
</font>
</body>
</html>