couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: couchdb transactions changes
Date Wed, 11 Feb 2009 21:43:59 GMT
Hi Antony. Just to clarify, there is no vote, as there is no patch  
ready yet. And I think you don't want to vote against the patch, you  
want to vote against the removal of guaranteed interactive conflict  
checking. Though the code is very much intertwined, the rest of the  
patch (replication security and optional revision stemming) is not  
directly related to semantics how bulk transactions work.

To be clear, the reason I don't want to all of nothing transactions w/  
conflict checking is I don't know how we'll support it in partitioned  
cluster. For an example of something I know can support my proposed  
models, see this posting by Ricky Ho:

As far as distributed transactions go, I'd be thrilled if we could  
implement it and also support the rest of couchdb, like views and bi- 
directional replication. Please start up a discussion here in dev@  
about it and see if you can work out a design.

There was another use case presented in user@ that was interesting to  
me. I'm not sure it's necessary (or even correct) for their case, but  
I'm thinking that maybe we should allow all-or-nothing transactions  
with guaranteed conflict checking, but making it hard to enable, or  
require to pass in a flag name like "non-partitioned-and-non- 
replicable-transaction=true", so that it advertises it's limitations.  
It's bad to have misleading features, and cause people relying on  
CouchDB to do things it can't really do.


On Feb 11, 2009, at 3:27 PM, Antony Blakey wrote:

> I vote against this patch for the following reasons:
> 1. My reading of the Bayou research has shown me that transactions  
> can work with replication. The nature of a transaction is an  
> interesting issue, but orthogonal to this argument.
> 2. It's not clear on the real performance hit in a partitioned  
> database. Furthermore, the hit may be highly dependent on the  
> configuration and details of the write e.g. application design may  
> result in transactions always going to one shard.
> 3. In any case, I argue that it should be up the user whether to  
> tradeoff a possible performance hit for a ACID semantics.
> 4. I'm not convinced of the utility of the two models proposed as  
> replacements for the bulk operations. IMO it would be better to not  
> have a bulk operation than to have the proposed models.
> 4. The justification is dependent on the implementation details of a  
> future feature that isn't itself described or known. From a  
> procedural point of view therefore it's not possible to assess this  
> argument because the community has no way of assessing it's validity.
> 5. This argument is also dependent on another argument that CouchDB  
> must provide a single API over  both single-node and multi-node  
> operation, and must not allow the user to take advantage of the  
> differences. I disagree with that, but in any case it's not an  
> argument that has been put and resolved by the community.
> On 08/02/2009, at 2:17 AM, Damien Katz wrote:
> [snip]
> Antony Blakey
> -------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
> There is nothing more difficult to plan, more doubtful of success,  
> nor more dangerous to manage than the creation of a new order of  
> things... Whenever his enemies have the ability to attack the  
> innovator, they do so with the passion of partisans, while the  
> others defend him sluggishly, So that the innovator and his party  
> alike are vulnerable.
>  -- Niccolo Machiavelli, 1513, The Prince.

View raw message