couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject couchdb transactions changes
Date Sat, 07 Feb 2009 15:47:01 GMT
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  

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.


View raw message