couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <>
Subject Bulk updates and eventual consistency
Date Thu, 19 Mar 2009 05:50:24 GMT
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...



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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message