couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: couchdb transactions changes
Date Sat, 07 Feb 2009 16:22:34 GMT

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.


> 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