[erlang-questions] Mnesia transaction restarts
Bernard Duggan
bduggan@REDACTED
Tue Oct 28 05:57:53 CET 2014
On 27/10/14 20:43, Ulf Wiger wrote:
On 27 Oct 2014, at 01:17, Bernard Duggan <bduggan@REDACTED<mailto:bduggan@REDACTED>> wrote:
But since it *is* happening there must be some property of our system that I don't fully understand. Time to go digging again :)
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)).
Thanks Ulf. Inconveniently, this is only a single-node system, so there's no opportunity for distribution systems to get in the way :)
Dan will have to correct me if I’m wrong here...
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).
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 :)
[snip]
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.
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.
Cheers,
Bernard
________________________________
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141028/a7ead087/attachment.htm>
More information about the erlang-questions
mailing list