Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of david.vancouvering@gmail.com
 designates 209.85.132.240 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:date:x-google-sender-auth:message-id:subject
         :from:to:content-type;
        b=J1Cd74e1wTFauBLMQ5fF43g8rTZkRODiIf5C1H2qJk+hbvdmI9j6UKR3VOg7krVml0
         FdFJvWSnMkq3bZoKrY71UqawIVFeIH55zpTO/GzRfz5dmjvjvX7l8igkscO1XuRbeboo
         TajYBhAD+e9SfPuTDytnHZk22Cs5uY/i8IirE=
MIME-Version: 1.0
Sender: david.vancouvering@gmail.com
Date: Wed, 18 Mar 2009 22:50:24 -0700
Message-ID: <56a83cd00903182250l5aaec9c2g8815899f32e6924a@mail.gmail.com>
Subject: Bulk updates and eventual consistency
From: David Van Couvering <david@vancouvering.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=00221532cf6c64b95a04657260d6

--00221532cf6c64b95a04657260d6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi, all.  I'm working on updating the Wiki to describe the new behavior of
bulk updates.

I read the very (very) long thread about Damien's change to the
transactional semantics around _bulk_docs, and I understand the situation
pretty well (I think).  But there's one part of the discussion that I wanted
to make sure I had correct.

My understanding is that one motivation for bulk update may be because you
have referential dependencies between docs.  If there are no conflicts, then
you can be assured those references will be consistent on the database where
you do the bulk update (with all-or-nothing), *but* they may not immediately
be consistent on replicas.  This is because a bulk update is not replicated
all-or-nothing, but instead each document is replicated independently, in an
unspecified order.  So you will have a temporary state of affairs where the
references between documents may be inconsistent, but eventually they do
become consistent (for that particular bulk update).

*But* if you *do* have conflicts in a bulk update, then it is quite possible
that the choice of winners for the conflict will cause a referential
inconsistency between documents.  In this case, the inconsistency will *not*
automatically become eventually consistent, but will require intervention by
the application to resolve the documents to a consistent state.

This can happen even when you are not using replication at all, but you have
two simultaneous sessions update the same document.

In the previous implementation, bulk_update rolled back if there were any
"local" conflicts, so you were guaranteed of referential consistency between
docs on the database instance where you applied the bulk update.  However,
you could still end up in a pickle if replication caused a conflict -- now
you are back in the same place with referential inconsistency that has to be
manually resolved.

Do I have that right?

I am uncomfortable about asking the next question, as I feel I am opening up
a can of worms, but I am missing what problem was solved by allowing
all-or-nothing to succeed on conflicts.   It seems like in both models you
have eventual consistency and interim states where documents are
inconsistent, but at least with the old approach you were guaranteed
consistency on the database instance where you did the bulk update.  That
seems like it could be pretty handy, particularly for deployments where you
are not doing replication.

My apologies if this was already answered in that very long thread, but
perhaps someone can summarize for me...

Thanks,

David

-- 
David W. Van Couvering

I am looking for a senior position working on server-side Java systems.
 Feel free to contact me if you know of any opportunities.

http://www.linkedin.com/in/davidvc
http://davidvancouvering.blogspot.com
http://twitter.com/dcouvering

--00221532cf6c64b95a04657260d6--