couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <antony.bla...@gmail.com>
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


Mime
View raw message