couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <>
Subject Re: couchdb transactions changes
Date Sun, 08 Feb 2009 06:20:11 GMT

On 08/02/2009, at 4:35 PM, Damien Katz wrote:

>> So just to be clear, replication ignores MVCC?
> No, it still uses MVCC, just not at transaction boundaries.

Surely MVCC is only about 'transactions'. Even if it's an issue of on- 
disk ACID.

> No it wouldn't, because some of the documents that it's about to  
> read for previous updates might be updated again during replication.

Outgoing replication doesn't change the documents it's sending does  
it? Or are you suggesting concurrent incoming/outgoing replication? Or  
simply concurrent operation? If the case of concurrent updating during  
replication, MVCC gives you static snapshot of the data, so the  
outgoing replication can be relative to the commit id at the time that  
the replication is initiated, just like a view.

> Technically it's possible for the database to never be completely  
> consistent, but for many previous transactions to become consistent,  
> and then overwritten by later temporarily inconsistent states.
> But updates are never lost, however they might be delayed a bit.  
> Eventually consistent doesn't mean the database as a whole will  
> eventually be consistent at any snapshot, but all the individual  
> inconsistencies are transient and go away.

Or might not, which sounds like a very difficult issue to deal with in  
an application.

> Great, you have an app server to front it. Just serialize all  
> updates to the database do the conflict checking in the app layer.  
> Then commit. You don't get good update throughput, but you do get  
> the user interaction you desire.

And I get a horrendous API and awful performance.

Antony Blakey
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Success is not the key to happiness. Happiness is the key to success.
  -- Albert Schweitzer

View raw message