<div dir="ltr">In my experience you make these things happen yourself on the application level.<div><br></div><div>Although the transaction you are describing is only accessing one record, there might be another process that takes a whole table lock and keeps running for some time. This is usually some reporting process or some maintenance process, where you didn't realize that you were taking a whole table lock. Such locks are implicitly taken by qlc:s, matches and selects when you do them in a transaction.</div><div><br></div><div>If you don't have such processes, I would look for careless try/catch patterns that execute in a transaction. Since the restarts in mnesia transactions are signaled with exceptions you need to be very careful with what you are catching in the code inside a transaction. This could make another transaction that should have been restarted ending up catching the restart signal and keep the lock.</div><div><br></div><div>Just my 2c</div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-10-28 5:57 GMT+01:00 Bernard Duggan <span dir="ltr"><<a href="mailto:bduggan@shoretel.com" target="_blank">bduggan@shoretel.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div bgcolor="#FFFFFF"><span class="">
<br>
<div>On 27/10/14 20:43, Ulf Wiger wrote:<br>
</div>
<blockquote type="cite"><br>
<div>
<div>On 27 Oct 2014, at 01:17, Bernard Duggan <<a href="mailto:bduggan@shoretel.com" target="_blank">bduggan@shoretel.com</a>> wrote:</div>
<br>
<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;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing: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>
</blockquote></span>
Thanks Ulf. Inconveniently, this is only a single-node system, so there's no opportunity for distribution systems to get in the way :)<span class=""><br>
<br>
<blockquote type="cite">
<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>
</blockquote></span>
I have noticed (and been tripped up by) that selective receive in the past. I even took a look at one stage at whether it could be new-reference optimised, but quickly gave up. In at least one sense I'm glad to hear you say that it is, in fact, unoptimisable
 because it means I was right to not spend too much time on it :)<br>
<br>
<blockquote type="cite">[snip]
<span class=""><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>
</span></blockquote>
Thanks - it's something we've definitely tried to keep in mind, making sure we avoid debug logging etc inside the transactions. I will, however, go back and re-check a few critical places to make sure we're not doing something silly.<span class=""><br>
<br>
Cheers,<br>
<br>
Bernard<br>
<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>
</span></div>

<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">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>
<br></blockquote></div><br></div>