couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <dam...@apache.org>
Subject Re: couchdb transactions changes
Date Thu, 12 Feb 2009 00:06:31 GMT

On Feb 11, 2009, at 5:36 PM, Antony Blakey wrote:

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

Just take the initiative and drive the discussion. Or write the  
code :) No need to wait on me or anyone else, ever. This is a  
community driven project after all.

-Damien

Mime
View raw message