couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: couchdb transactions changes
Date Sat, 07 Feb 2009 16:02:13 GMT
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?



On Feb 7, 2009, at 10:47 AM, Damien Katz <damien_katz@yahoo.com> 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
>

Mime
View raw message