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:31:02 GMT

On Feb 11, 2009, at 7:06 PM, Damien Katz wrote:

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

Sorry, to answer your question directly, I haven't really thought  
about it, but I don't have anything in the works that I can see would  
be incompatible with any new distributed transaction model. Not  
anymore than things already might be.

But even if I did, don't let that stop you.

-Damien

Mime
View raw message