couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Update of "HTTP Document API" by DavidVanCouvering
Date Sun, 22 Mar 2009 14:16:41 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The following page has been changed by DavidVanCouvering:
http://wiki.apache.org/couchdb/HTTP_Document_API

------------------------------------------------------------------------------
  
  - 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 partitioned (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 consistently in single-node, replicated and partitioned environments. There are now
two transactional models supported:
+ 
+    * *non-atomic* (default) - some documents may successfully be saved and some may not.
 It is up to the application to check that all documents were successfully saved/updated.
+ 
+    * *all-or-nothing* - either all the documents will commit successfully or none will.
However, it does not do conflict checking, so the documents will be committed even if there
are conflicts. Conflicting versions of the document will be saved. 
+ 
+ - non-atomic - In this mode, 
+ 
+ 
+ ---- /!\ '''Edit conflict - other version:''' ----
+ == Transactional Semantics with Bulk Updates ==
+ 
+ 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 consistently in single-node, replicated and partitioned environments. There are now
two transactional models supported:
@@ -386, +404 @@

  
  - non-atomic - In this mode, 
  
+ 
+ ---- /!\ '''Edit conflict - your version:''' ----
+ 
+ ---- /!\ '''End of edit conflict''' ----
  === DELETE ===
  
  To delete a document, perform a ''DELETE'' operation at the document's location, passing
the ''rev'' parameter with the document's current revision. If successful, it will return
the revision id for the deletion stub.

Mime
View raw message