From 5d94c1db66883d14825c49bc9bba191199bc9ea8 Mon Sep 17 00:00:00 2001 From: Austin Clements Date: Fri, 3 Oct 2014 15:18:44 +2000 Subject: [PATCH] Re: [PATCH v3] lib: Simplify close and codify aborting atomic section --- 95/2d6d668b91dfe5f90592ea69a3a9e7d8c76d65 | 100 ++++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 95/2d6d668b91dfe5f90592ea69a3a9e7d8c76d65 diff --git a/95/2d6d668b91dfe5f90592ea69a3a9e7d8c76d65 b/95/2d6d668b91dfe5f90592ea69a3a9e7d8c76d65 new file mode 100644 index 000000000..fb8691ba8 --- /dev/null +++ b/95/2d6d668b91dfe5f90592ea69a3a9e7d8c76d65 @@ -0,0 +1,100 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 2CA8F431FBC + for ; Thu, 2 Oct 2014 12:18:54 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -2.3 +X-Spam-Level: +X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id Mw4ox0DrvKFq for ; + Thu, 2 Oct 2014 12:18:48 -0700 (PDT) +Received: from outgoing.csail.mit.edu (outgoing.csail.mit.edu [128.30.2.149]) + by olra.theworths.org (Postfix) with ESMTP id 00ECA431FB6 + for ; Thu, 2 Oct 2014 12:18:47 -0700 (PDT) +Received: from [104.131.20.129] (helo=awakeningjr) + by outgoing.csail.mit.edu with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) + (Exim 4.72) (envelope-from ) + id 1XZltk-0007rB-QU; Thu, 02 Oct 2014 15:18:44 -0400 +Received: from amthrax by awakeningjr with local (Exim 4.84) + (envelope-from ) + id 1XZltk-0005Xo-8v; Thu, 02 Oct 2014 15:18:44 -0400 +From: Austin Clements +To: "W. Trevor King" +Subject: Re: [PATCH v3] lib: Simplify close and codify aborting atomic section +In-Reply-To: <20140924213910.GF20130@odin.tremily.us> +References: <20140924212839.GE20130@odin.tremily.us> + <1411594370-9794-1-git-send-email-aclements@csail.mit.edu> + <20140924213910.GF20130@odin.tremily.us> +User-Agent: Notmuch/0.18.1+86~gef5e66a (http://notmuchmail.org) Emacs/24.3.1 + (x86_64-pc-linux-gnu) +Date: Thu, 02 Oct 2014 15:18:44 -0400 +Message-ID: <87mw9ee0vf.fsf@csail.mit.edu> +MIME-Version: 1.0 +Content-Type: text/plain +Cc: notmuch@notmuchmail.org +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Thu, 02 Oct 2014 19:18:54 -0000 + +On Wed, 24 Sep 2014, "W. Trevor King" wrote: +> On Wed, Sep 24, 2014 at 05:32:50PM -0400, Austin Clements wrote: +>> + * If the caller is currently in an atomic section (there was a +>> + * notmuch_database_begin_atomic without a matching +>> + * notmuch_database_end_atomic), this will abort the atomic section, +>> + * discarding any modifications made in the atomic section. All +>> + * changes up to this will be committed. +> +> I still think Xapian's wording is more readable [1]: +> +> For a WritableDatabase, if a transaction is active it will be +> aborted, while if no transaction is active commit() will be +> implicitly called. +> +> How about: +> +> For a writable database, if a transaction is active (there was a +> notmuch_database_begin_atomic without a matching +> notmuch_database_end_atomic) it will be aborted, while if no +> transaction is active any pending changes will be committed. + +What is a "pending change" from the perspective of the notmuch API? +This is tricky because basically nothing in the library talks about +durability (partly because the notmuch API provides almost no control +over it). Likewise, the API doesn't expose the notion of a transaction +(since that generally implies ACID), but only atomic sections. + +I actually find the Xapian wording rather confusing. Neither Xapian's +documentation nor your suggested comment say what happens when there is +*both* an outstanding transaction and pending changes. In fact, teasing +this out made me realize that Xapian might in fact discard committed +(but unflushed) changes if you close the database with an outstanding +transaction. But we definitely do want to flush these transactions +(especially since *all* of our atomic sections are "unflushed +transactions"). In v4 I've added some code to make sure this happens, +but because of the vagueness of the documentation I have no idea if it's +necessary. + +> Cheers, +> Trevor +> +> [1]: http://xapian.org/docs/apidoc/html/classXapian_1_1Database.html#a59f5f8b137723dcaaabdbdccbc0cf1eb +> +> -- +> This email may be signed or encrypted with GnuPG (http://www.gnupg.org). +> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -- 2.26.2