couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Shumaker <>
Subject Re: New bulk docs behavior - transactional
Date Sun, 05 Apr 2009 21:11:11 GMT
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'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,
>>    - 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).
>>    - 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, and
> indeed it could be done in a sharded environment too. However it would be
> extremely difficult to implement if you allow multi-master replication too.
> 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.

View raw message