<div dir="auto">Hello Jesper,</div><div dir="auto"><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><div class="gmail_quote"><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif" dir="auto">[..] If we lose power in the middle of a transaction, we want the database to come back either with the transaction comitted or not. We don't want a halfway transaction. We could achieve this by writing all our intentions down in a log, together with commit points. When the system then boots again, we replay the log from the genesis point up until the last good transaction commit point. Everything after that point, we discard and regard as not having happened.</div></div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">By log here you refer to LATEST.LOG, right?</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><div class="gmail_quote"><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif" dir="auto">However, that log might grow very large. So we want a way to circumvent indefinite growth. We can do this by keeping a snapshot of our tables on disk. Then we only need to keep a global log from the last snapshot point and forward rather than having to keep the full log available for replay. But taking snapshots is a relatively expensive operation too. So we keep a "local" log for each table.</div></div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">How these local logs are named?</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><div class="gmail_quote"><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif" dir="auto">The current state is the snapshot + a replay of the local log. New transactions enter the global log first, and are then flushed out to the local logs. The next dump folds the local log into a new snapshot, so we can delete the local log and create a new local log for future changes.</div></div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">Got it. </div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><div class="gmail_quote"><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif" dir="auto"></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Getting this to work is quite complicated, and it isn't made simpler by the fact that mnesia can also run in a distributed mode, where data is replicated among several nodes, and you have to handle several impossibility results from distributed computing.</div></div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">Where can I find more info on the Mnesia internals besides reading the code?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><div class="gmail_quote"><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif" dir="auto"></div></div></div></div>
</blockquote></div></div>