From dev-return-3781-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Sun Apr 05 21:11:41 2009
Return-Path:
Delivered-To: apmail-couchdb-dev-archive@www.apache.org
Received: (qmail 26896 invoked from network); 5 Apr 2009 21:11:41 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
by minotaur.apache.org with SMTP; 5 Apr 2009 21:11:41 -0000
Received: (qmail 67844 invoked by uid 500); 5 Apr 2009 21:11:40 -0000
Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org
Received: (qmail 67754 invoked by uid 500); 5 Apr 2009 21:11:40 -0000
Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@couchdb.apache.org
Delivered-To: mailing list dev@couchdb.apache.org
Received: (qmail 67744 invoked by uid 99); 5 Apr 2009 21:11:40 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 05 Apr 2009 21:11:40 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of sshumaker@gmail.com designates 74.125.44.29 as permitted sender)
Received: from [74.125.44.29] (HELO yx-out-2324.google.com) (74.125.44.29)
by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 05 Apr 2009 21:11:32 +0000
Received: by yx-out-2324.google.com with SMTP id 8so1092230yxb.5
for ; Sun, 05 Apr 2009 14:11:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:in-reply-to:references
:date:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=KHQH8Wq6WTZPrWWIJnezRKfjF4nQL0qO8W4kJ17mTvc=;
b=MD3v8EyPgNPqQ0bbXA8ybwxdXubrUzOeXATlX8Ls9B9d8cktlWa/iklNLXkYRzgQ2k
FLDELjhi2lJzlPKAMJORljYjohODTiKifxvW6A9bDL7g9v5TOUbwz8YqPETEjdk/uyLw
y+sSrX0Tov4KVXYpCkwc78sMJpbKt77AlcsOY=
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
:cc:content-type:content-transfer-encoding;
b=wbobvCA4psbmMQv/3WJH6MvheRP1Urhz8nJXgY3nAYrCI+X1H+ALO++pePmv55dxE8
FRsGPHqzErGc3uCKsdpHLazID9vIo9pKwQJiWfLbMyFBWG1edsAd1bRVlQjD4pRJzydq
tszxJ1/Co0YMCQC3KHc+1iTjyrXWdJoVYx+iM=
MIME-Version: 1.0
Received: by 10.150.134.21 with SMTP id h21mr5630092ybd.248.1238965871190;
Sun, 05 Apr 2009 14:11:11 -0700 (PDT)
In-Reply-To: <20090405194602.GA11590@uk.tiscali.com>
References: <261cf6280904022309u4f008066gf38d0a0dbcb97199@mail.gmail.com>
<20090405194602.GA11590@uk.tiscali.com>
Date: Sun, 5 Apr 2009 14:11:11 -0700
Message-ID: <261cf6280904051411u3637488fp4df800167ccf411e@mail.gmail.com>
Subject: Re: New bulk docs behavior - transactional
From: Scott Shumaker
To: Brian Candler
Cc: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Checked: Checked by ClamAV on apache.org
Effectively, yes. But I feel that representing this as a hidden rev
fits more into the current model. Instead of a lock, you just have a
new hidden rev that the clients can't see, but there would probably be
a way to retrieve it, in the same kind of way you can retrieve
conflicted versions of a document.
For Multi-master replication, this really shouldn't change anything.
The hidden rev won't replicate to other masters, bug 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.
Although as an aside, I'm not sure how multi-master replication could
really work in a production system for most kinds of data, even in the
standard (non-transactional) case. The fact that 'an arbitrary rev'
shows up in views as a result of the conflict seems like it would have
unacceptable consequences most of the time. To see why, examine the
behavior you typically need when you're doing a simple write and get a
conflict (because another client got there first). It turns out that
the conflict resolution behavior is very case-specific. Sometimes you
need to just refresh the latest version. Other times, you choose one
based on a timestamp. Sometimes you need to merge the two, and
present interface to the client to do so (like Amazon.com's merge
shopping carts screen). Noticing conflicts later on with some sort
of cronjob often doesn't give you enough information to decide what to
do - and if you require user intervention to resolve the conflict,
this definitely won't work! So the fact that replication conflicts
don't have symmetric behavior with standard write conflicts makes
multi-master replication untenable for most needs.
On Sun, Apr 5, 2009 at 12:46 PM, Brian Candler wrote:
> On Thu, Apr 02, 2009 at 11:09:24PM -0700, Scott Shumaker wrote:
>> How about something like the following?
>>
>> During an 'transactional bulk write':
>>
>> - For each document in the transaction,
>>
>> =A0 =A0- 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).
>> =A0 =A0- 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).
>
> In that case, is this new magic rev not just the same as a lock?
>
> Implementing a per-document lock within one database is simple enough, an=
d
> indeed it could be done in a sharded environment too. However it would be
> extremely difficult to implement if you allow multi-master replication to=
o.
> You would also need procedures to recover locks due to transactions which
> have stalled or silently aborted (remembering that HTTP is a stateless
> protocol)
>
> Regards,
>
> Brian.
>