couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <dam...@apache.org>
Subject Re: couchdb transactions changes
Date Sun, 08 Feb 2009 06:35:26 GMT

On Feb 8, 2009, at 1:20 AM, Antony Blakey wrote:

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

In this case it has nothing to do with update transactions. MVCC is  
about each read operation having it's own snapshot of the database.

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

I'm stating that you must "read lock" the source database if you want  
this "consistent replication" thing you are trying to achieve. That's  
a fact.

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

Which is why in general you want to avoid inter-document dependencies,  
or be relaxed in how you deal with them.

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

The API will be identical except for this checking phase during update  
and the performance will be quite fast, you just need to check the rev  
for a bunch of documents. There is already a built in api for doing  
that check that's used by the replicator (to avoid unnecessary  
resending documents that are already at the target). It should only  
add maybe 20% roundtrip overhead time.

-Damien

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


Mime
View raw message