<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 27 Oct 2014, at 01:17, Bernard Duggan <<a href="mailto:bduggan@shoretel.com">bduggan@shoretel.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); float: none; display: inline !important;">But since it *is* happening there must be some property of our system that I don't fully understand. Time to go digging again :)</span></blockquote><br></div><div>If the writes are replicated, you might want to look for overload conditions on remote mnesia_tm processes (e.g. due to mnesia_overload (message_queue_len)).</div><div><br></div><div>Dan will have to correct me if I’m wrong here...</div><div><br></div><div>If a younger (WaitForTid < OurTid) transaction gets held up on commit, older transactions can get stuck in a restart condition. Since the mnesia_tm process relies on (unoptimizable) selective receive, it’s vulnerable to long message queues (which can happen especially if you have lots of replicated dirty writes).</div><div><br></div><div>Note that when comparing tids from different nodes, the words ‘younger’ and ‘older' doen’t necessarily correspond to a true global ordering. The comparison is essentially {Counter, Pid}, and the Counter is node-local, incremented for each transaction start/restart. The important thing for the deadlock prevention is that the comparison rules are globally consistent (that is, produce the same result regardless of *where* the comparison takes place).</div><div><br></div><div>The mnesia_locker process has no blocking conditions that I know of. A lock request for a replicated read or write will loop through the ‘where_to_read’/‘where_to_write’ list and ask each locker in turn. The list is sorted, but the local node (if present) is always first. Locks are released when instructed by the mnesia_tm process (on commit/abort).</div><div><br></div><div>If you have side-effects inside transactions (message send/receive), basically all bets are off, and really weird things can happen, not least transaction processes waiting endlessly for messages that were already sent+received, but then discarded due to transaction restart.</div><div><br></div><div>BR,</div><div>Ulf W</div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div><div>Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.</div><div><a href="http://feuerlabs.com">http://feuerlabs.com</a></div></div><div><br></div></span><br class="Apple-interchange-newline">
</div>
<br></body></html>