couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <>
Subject Re: couchdb transactions changes
Date Wed, 11 Feb 2009 22:36:47 GMT

On 12/02/2009, at 8:13 AM, Damien Katz wrote:

> Hi Antony. Just to clarify, there is no vote, as there is no patch  
> ready yet.

Sorry Damien, jumped the gun.

> And I think you don't want to vote against the patch, you want to  
> vote against the removal of guaranteed interactive conflict checking.

I'm not keen on either of the transaction models presented for use  
with _bulk_docs. The first is as you say, but also the second, because  
it removes write-ordering consistency. Obviously caveat user applies,  
but I think it's too dangerous.

> 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.

I have no issue with those given that they are both optional, although  
I am interested in an alternative model of history truncation that is  
linear wrt the db rather than each document, but that's a separate  
issue and I've yet to translate that from the extant research to  

> 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:

Sure, and I think that's the right impulse. I think it would be better  
to either

1. Commit to _bulk_docs continuing to work in a single-node case; or
2. Remove it completely until we better understand the design and  
constraints of the partitioned CouchDB, and hence the possibilities  
and trade-offs for some kind of ACID. My take is that it will be  
possible, and the issue will be the cost, which I think should be in  
the hands of the user.

Obvious Ricky Ho's model has certain implications, but I'm not sure  
that it's the right model for clustering. Putting a proxy into the mix  
sounds like it really should be middleware, with it's own operational  
contract. I think a less loosely coupled clustering model would be  
superior, but then I don't regard fractal uniformity as an ultimate  

> 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.

Distributed transactions is a very misleading term in this  
environment. I think the weak-consistency guarantees can be slightly  
stronger than CouchDB, but they're still weak. The closure of the  
reference graph from Bayou will take a while to follow, but even so, I  
think replication that maintains write-dependencies is relatively easy  
to do. One key is to recognize that the a local transaction can have  
either fail-on-conflict or commit-on-conflict semantics in an ACID  
manner, but replication transactions are always commit-on-conflict.  
It's obviously important not to confuse the consistency of ACID with  
the conflict of weak-consistency.

Anyway, I'll hold off on further discussion until I see your changes  
because the devil's in the details, and I'm under the impression that  
you have some extensive changes in the pipeline?

> 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.

Agreed, with the caveat that CouchDB in different configurations can,  
and IMO should have configurable semantics.

Antony Blakey
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

You can't just ask customers what they want and then try to give that  
to them. By the time you get it built, they'll want something new.
   -- Steve Jobs

View raw message