<div dir="ltr">Hey Menno,<div><br></div><div>I'm copying the list to ensure we have this documented somewhere for future reference.</div><div><br></div><div>You are right that it's not that simple, but it's not that complex either once you understand the background.</div><div><br>Transactions are applied by the txn package by tagging each one of the documents that will participate in the transaction with the transaction id they are participating in. When mgo goes to apply a transaction in that same document, it will tag the document with the new transaction id, and then evaluate all the transactions it is part of. If you drop one of the transactions that a document claims to be participating in, then the txn package will rightfully complain since it cannot tell the state of a transaction that explicitly asked to be considered for the given document.</div><div><br></div><div>That means the solution is to make sure removed transactions are 1) in a final state; and 2) not being referenced by any tagged documents.</div><div><br></div><div>The txn package itself collects garbage from old transactions as new transactions are applied, but it doesn't guarantee that right after a transaction reaches a final state it will be collected. This can lead to pretty old transactions being referenced, if these documents are never touched again.</div><div><br></div><div>So, you have two choices to collect these old documents:</div><div><br></div><div>1. Clean up the transaction references from all documents </div><div><br></div><div>or</div><div><br></div><div>2. Just make sure the transaction being removed is not referenced anywhere</div><div><br></div><div>I would personally go for 2, as it is a read-only operation everywhere but in the transactions collection itself, to drop the transaction document.</div><div><br></div><div>Note that the same rules here apply to the stash collection as well.</div><div><br></div><div>Please let me know if you run into any issues there.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 12, 2015 at 9:21 PM, Menno Smits <span dir="ltr"><<a href="mailto:menno.smits@canonical.com" target="_blank">menno.smits@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi again,<br><br>In response to the current production Juju issue, I've been tasked with adding something to Juju to keep the size of Juju's txns and txns.log collections under control so that they don't  grow unbounded. <br><br></div>The ticket is here: <a href="https://bugs.launchpad.net/juju-core/+bug/1453785" target="_blank">https://bugs.launchpad.net/juju-core/+bug/1453785</a><br><div><br></div><div>Naively, one might think that transactions could be removed if they were (say) over a week old and marked as either applied or aborted but of course it's not that simple[1]. I must admit that I don't completely understand why this is case, even when I look at the code for mgo/txn. How does a pending transaction end up depending on the details of an applied transaction?<br><br>Given that a typical Juju system has no maintenance window and there's (currently) no way to put a Juju system into a "read-only" mode can you think of  any practical way for Juju to prune the txn and txn.stash collections?<br><br></div><div>Any ideas would be most helpful.<br><br></div><div>- Menno<br></div><div><br>[1] <a href="http://grokbase.com/t/gg/mgo-users/13cj7c6kxt/when-to-delete-db-transaction" target="_blank">http://grokbase.com/t/gg/mgo-users/13cj7c6kxt/when-to-delete-db-transaction</a><br><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a></div>
</div>