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 01:23:16 GMT

On 08/02/2009, at 11:46 AM, Damien Katz wrote:

> On Feb 7, 2009, at 6:14 PM, Antony Blakey wrote:
>> On 08/02/2009, at 9:35 AM, Damien Katz wrote:
>>> I think this works in situations where you have only a single  
>>> machine (no replication, no failover), or your app can have read  
>>> only slaves nodes where readers don't care about db consistency  
>>> (but still no failover). I'm not sure that fits many real world  
>>> use cases.
>> If you have read-only slaves, then they won't be inconsistent  
>> outside of a replication. This is my current deployment model, with  
>> a very large number of users, where every user is potentially  
>> running a copy of 'Desktop CouchDB' (cf the contract I posted).  
>> This is CouchDB as Notes Client, not as a server per-se.
> During replication, you don't get any sort of interdocument  
> consistency guarantee or even update ordering. During replication,  
> the clients will see random updates until the replication is fully  
> complete. If the downstream clients lose their connection halfway  
> during an replication, they won't have a consistent database.

Sure, but this isn't an issue if your app allows for a replication- 
mode that is exclusive to normal application mode i.e. doesn't switch  
until it gets a completed replication.

I think the issue you are addressing will only occur if replication is  
concurrent with 'normal' operation. For applications the require  
consistency, this need not be the case.

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

The greatest challenge to any thinker is stating the problem in a way  
that will allow a solution
   -- Bertrand Russell

View raw message