Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of sshumaker@gmail.com
 designates 209.85.217.162 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=Hv1ocH832yLq7rdr+a0U8ennZMtaPc7UXW9R/emoYR/4rIZjBAEilJn3Mamusisa0G
         0Jm21LBEIS1wfBjmIVIrzo0PC7BdEO7Ycltp+UUDd67xwzsKaGn9d/tkkOJQLKoD3rMM
         dbUKk3o3eaDprqavpB371gbjhO0gi67j3iy9A=
MIME-Version: 1.0
In-Reply-To: <DC62CD36-0887-4574-8060-BE67D4F89F2A@gmail.com>
References: <bf83b4ef0904020449j23827c4fl746aed435f6b6ab@mail.gmail.com>
	 <49D61D2B.7090600@proven-corporation.com>
	 <49D62252.1050007@timparkin.co.uk>
	 <49D62402.2010904@proven-corporation.com>
	 <bf83b4ef0904030822g563d9a8sde3c371ec47c67f8@mail.gmail.com>
	 <EFD9017A-C722-4890-83E6-14114B9A3D49@gmail.com>
	 <49D7206D.7010907@gmx.de>
	 <CB9BE9A0-D888-4E89-9AD4-0494D91E9427@gmail.com>
	 <bf83b4ef0904040418j66f53a2aq82b5cd4964700cc@mail.gmail.com>
	 <DC62CD36-0887-4574-8060-BE67D4F89F2A@gmail.com>
Date: Sun, 5 Apr 2009 14:16:50 -0700
Message-ID: <261cf6280904051416j77d7f85eja7c1f4fe96b08ca2@mail.gmail.com>
Subject: Re: how to ensure transactions over multiple documents?
From: Scott Shumaker <sshumaker@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Cross-posting from dev, since this may be a better forum:

How about something like this to implement transactions?

During an 'transactional bulk write':

- For each document in the transaction,

  - Attempt to create a new rev of the document, specially flagged so
it doesn't show up in views, document fetches, or replications (return
the last version of this documents instead).  While hidden, There
would probably be some way to retrieve them, like the way you retrieve
conflicted versions currently.
  - This rev SHOULD be examined when checking for conflicts with
subsequent writes (so no new writes to the document can happen while
the transaction is in progress - they return with a conflict error).

- If all of the documents in the transaction are created successfully
(pass document validation, don't conflict with earlier revs), remove
the flags from these revisions (therefore becoming standard revs in
the database).  If not, remove these newly created revs.

This would sort of give a loose form of two-phase commit that should
work over sharded databases.  There's obviously a higher performance
cost - it's equivalent to two writes (once to write these 'shadow'
revisions, and once again to remove the flags on success or prune the
revisions on failure).  And clients won't be able to write to any of
the documents in the transaction until it completes (effectively
locking them for write), because they won't be able to
see the latest version.  But it would probably achieve the effect that
most people want.  And naturally, it
wouldn't be the default bulk_write behavior (given the cost and
limitations).

For Multi-master replication, this really shouldn't change anything.
The hidden rev won't replicate to other masters, but if another master
attempts to replicate a version over the top of the hidden rev, it's
treated exactly the same way as a standard multi-master conflict; it
will be flagged as conflicted, and one of them will show up in views.


On Sat, Apr 4, 2009 at 4:54 AM, Antony Blakey <antony.blakey@gmail.com> wro=
te:
>
> On 04/04/2009, at 9:48 PM, Andrius Juozapaitis wrote:
>
>> Antony: I was assuming (given a replication scenario) that I'll be
>> using one node as a =A0master, and spring would only access this node
>> for updates, while the others would be used for reading only.
>
> Certainly for very specific architectures there are workable solutions -
> yours being one of them. My goal is to encourage the most general solutio=
n
> possible, as in my transactional git branch.
>
> If you eliminate relplication then you can completely wrap CouchDB's API =
and
> apply both significantly extended and quite different semantics (of cours=
e).
> In fact, this is how I think the app-server like features of CouchDB shou=
ld
> be done, rather than the current model. The problem is that CouchDB doesn=
't
> expose enough to do that wrapping once replication is involved.
>
> Antony Blakey
> --------------------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
>
> Don't anthropomorphize computers. They hate that.
>
>
>