Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-Id: <F3E85261-0557-4EAA-982A-305A243061D5@apache.org>
From: Damien Katz <damien@apache.org>
To: dev@couchdb.apache.org
In-Reply-To: <867439E1-D87A-4BCC-9732-94C1C6018B72@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: couchdb transactions changes
Date: Sat, 7 Feb 2009 20:35:53 -0500
References: <84F66023-030A-4669-B75C-3DCC92D71A78@yahoo.com>
 <3B1EB33E-D224-43E2-9FDC-D7493CD5BFDD@pobox.com>
 <59473D22-6EA5-4CE2-A193-8F4938C2D6BB@apache.org>
 <82C6FE57-1BBA-4E71-BDA4-0A1522608FEC@pobox.com>
 <BCBBBDEC-BB49-4B9B-9630-4851DD0F84E3@apache.org>
 <B63ABF9B-9980-4559-BFEA-888644591CC6@gmail.com>
 <4E84FF76-444A-48F9-A6F1-837800BCB7C9@apache.org>
 <867439E1-D87A-4BCC-9732-94C1C6018B72@gmail.com>


On Feb 7, 2009, at 8:23 PM, Antony Blakey wrote:

>
> 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.

But if the replication doesn't complete, like in the middle you lose  
your connection, then the downstream db is in an inconsistent state  
and will be until you regain the connection and complete the  
replication.

And its not just the downstream dbs that can't be used during active  
or interrupted replication, it's the central db as well. If you want  
to update it, you'll have to shut down access while waiting for any in  
progress replications to complete, then perform the update then reopen  
replication access.

-Damien

>
>
> 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
>