couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Van Couvering (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COUCHDB-223) Document a way to find out failed writes fro bulk requests and async writes
Date Thu, 19 Mar 2009 05:21:50 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683328#action_12683328
] 

David Van Couvering commented on COUCHDB-223:
---------------------------------------------

Here's the first draft of this.  It is missing example code, but I thought you could review
the overall description of the problem and new semantics while I'm poking around trying to
figure out what the example code should look like.  The tests are written in JavaScript, and
I can pull that code for an example, but shouldn't I also describe what the underlying HTTP
request should look like?

In previous releases of CouchDB, bulk updates were transactional - in particular, all requests
in a bulk update failed if any request failed or was in conflict.  There were a couple of
problems with this approach:

- This doesn't actually work with replication.  Replication doesn't provide the same transactional
semantics, so downstream replicas won't see "all-or-nothing" transactional semantics.  Instead,
they will see documents in an inconsistent state until replication of all documents involved
in the bulk update completes.  With bidirectional replication it can get even worse, because
you can get edit conflicts that must be fixed manually.

- If your database is partioned (aka "sharded"), different documents within the transaction
could live on different nodes in the cluster, and these kinds of transactional semantics don't
work unless you use heavy, non-scalable approaches like two-phase commit.

With release 0.9 of CouchDB, transactional semantics have been changed to make sure CouchDB
works well in replicated and partitioned environments.  There are now two transactional models
supported:

QUESTION: how does the user control which transactional model is used?  

- all-or-nothing - When using _bulk_docs to update a set of documents, either all the documents
will commit successfully or none will.  However, it does not do conflict checking the documents
will be committed even if there are conflicts.  Conflicting versions of the document will
be saved.  To use this approach, set the all_or_nothing flag when issuing a _bulk_docs request.

TODO: Provide example code here...

- non-atomic - In this mode, some documents may successfully be saved and some may not, and
it is up to the application to check that all documents were successfully saved/updated.

> Document a way to find out failed writes fro bulk requests and async writes
> ---------------------------------------------------------------------------
>
>                 Key: COUCHDB-223
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-223
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: Documentation
>            Reporter: Jan Lehnardt
>            Priority: Blocker
>             Fix For: 0.9
>
>
> A bulk docs request fails if one of the containing requests fail. In favour of multi-node
partitioning, this behaviour goes away and bulk writes will behave a lot like and async writes
and we should document the preferred way for clients to find failed writes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message