couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <antony.bla...@gmail.com>
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  
CouchDB.

> 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:
> http://horicky.blogspot.com/2008/10/couchdb-cluster.html

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

> 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




Mime
View raw message