couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: couchdb transactions changes
Date Sat, 07 Feb 2009 22:08:14 GMT

On Feb 7, 2009, at 11:22 AM, Damien Katz wrote:

> On Feb 7, 2009, at 11:02 AM, Geir Magnusson Jr. wrote:
>> Thanks for the info.  Is there a third mode possible?  Namely all  
>> or nothing  with conflict check,  with the understanimg that the  
>> conflict guarantee is only at commit, and all bets are off after  
>> that when replicated?
> That's what we currently have. It's possible to keep supporting it,  
> but it doesn't work with any of CouchDB's distributed features. It's  
> only appropriate for a single node instance, even a hot standby  
> slave will have inconsistent states.

Sure...  Assuming we're defining things the same way, I think that the  
existing mode still might be useful - I could consider a node to be  
the "reference master" for my data (or a subset) and vector all writes  
there with whatever consistency promises I get from a single node, and  
then everyone else will be eventually consistent, and I'd know that  
the eventually consistent nodes have a transactionally consistent data  

I realize I may not attach the same meaning to concepts, but can you  
get a sense of what I'm saying?


> -Damien
>> On Feb 7, 2009, at 10:47 AM, Damien Katz <>  
>> wrote:
>>> I'm working on a branch that implements couchdb the security  
>>> features with replication. It not done yet, but anyone is welcome  
>>> to look at the branch in /branches/rep_security.
>>> In this patch I am attempting to implement new transactions  
>>> models. The old transaction model has you all or nothing commits  
>>> for a group of docs, along with conflict checking. If any document  
>>> was in conflict, the transaction as a whole doesn't save.
>>> The problems with this are:
>>> 1. Transactions don't work with replication. Replication doesn't  
>>> repeat the bulk single transaction, it just copies the documents  
>>> individually to the target replica. This means any downstream  
>>> replica can and will sees inconsistent states until replication  
>>> fully completes, not "all or nothing" states. With bidirectional  
>>> replication is even worse, as you can get edit conflicts that must  
>>> be resolved by an external process, .
>>> 2. Transactions don't work in a partitioned database without a  
>>> huge performance hit (locking + 2 phase commits).
>>> So I propose supporting 2 different transaction models:
>>> This first is to support "All or nothing commits", but without  
>>> guaranteed conflict checking. So you can save bunch of documents  
>>> to the database and be sure they are all safely stored, or none  
>>> are safely stored, but you can't be guarantee you don't have any  
>>> conflicts when you do.
>>> The second is support non-acid bulk transactions, where some  
>>> document fail and some succeed. If the db crashes in the middle of  
>>> the transaction, some documents may have made it to disk  
>>> (completely intact), while others have not. The client will need  
>>> to check to be sure.
>>> With these 2 transactions models, it's possible to deploy the same  
>>> apps on a single machine or a huge partitioned cluster. To  
>>> support  the current model, it's only possible to deploy apps on a  
>>> single machine. I propose we drop the current model as bulk  
>>> transactions are not supportable in clustered or replicated set ups.
>>> -Damien

View raw message