<br><div class="gmail_quote">On Sun, Oct 30, 2011 at 3:59 AM, Dan Gudmundsson <span dir="ltr"><<a href="mailto:dangud@gmail.com">dangud@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
As far as mnesia is concerned it is logged to disc. It have left<br>
mnesia call chain and it's nothing<br>
more mnesia can do, except sync the disk.<br>
Which is a performance penalty that is not acceptable per transaction.<br>
<br></blockquote><div><br></div><div>"Not acceptable" to who? That's what a durable transaction *is*. For most users of actual databases, it is not acceptable that a (durable, isolated) transaction does *not* sync the disk when it claims to synchronize and its results are globally visible.</div>
<div><br></div><div>Imagine building a bank account balance transfer system on a database that allows globally visible changes to be rolled back. First, I transfer money to your account. Then, someone asks how much money you have to cover some payment. Then, the database crashes, and my transfer to you is reverted, even though the transfer was observed globally from outside the transaction. </div>
<div><br></div><div>Again, you can change the documentation if you want -- but from this discussion, I've learned something new -- what mnesia calls a transactional relational databse is not the same as what you'll find in a database systems textbook.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I have been reminded why the disc_log cache was implemented, when you<br>
push transactions<br>
in a short loop, you are pushing more transaction then what can be<br>
pushed to disc.<br></blockquote><div><br></div><div><br></div><div>This is what back pressure is for. If you need more peak throughput than your disk can provide (when including blocked commits) then you have to use non-synchronous "transactions" (which really aren't), and maybe a replicated table store in a second data center, to reduce the risk of permanent data loss. Mnesia can do this (neat!) similar to how systems like MongoDB can do this, but that's not a durable, isolated transaction system in the face of machine failure.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
So that everything was stuck in disc_logs message queue.<br>
The way to improve that was to write larger chunks to the disc.<br>
</blockquote><div><br></div><div><br></div><div>That's fine. A synchronous transaction commit should not be allowed until that larger block has committed, though. This means that you may collect many transactions waiting for commit, and they all commit with that particular block flush at the same time.</div>
<div><br></div><div><br></div><div>I think a note in the documentation would be useful. I think an implementation that blocks sync transactions until the block has flushed to disk (and thus, unblocking many synchronous transactions at once) might be even better!</div>
<div><br></div><div><br></div><div>Sincerely,</div><div><br></div><div>jw</div><div> </div></div><br>