couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: couchdb transactions changes
Date Sun, 08 Feb 2009 06:05:32 GMT

On Feb 8, 2009, at 12:37 AM, Antony Blakey wrote:

> On 08/02/2009, at 3:52 PM, Damien Katz wrote:
>> No, CouchDB replication doesn't support replicating the  
>> transactions. Never has, never will. That's more like transaction  
>> log replication that's in traditonal dbs, a different beast.
> So just to be clear, replication ignores MVCC?

No, it still uses MVCC, just not at transaction boundaries.

> And there is therefore no way to achieve any form of consistency,  
> even the weaker ACID you've proposed - which sounds like it's really  
> only Durability.

That's right, I'm not claiming inter-document ACID. CouchDB has never  
claimed that for replication. Ever.

> I presume it at least replicates according to update_seq? If so,  
> would it be difficult to ensure that the update_seq that the  
> replicator sees is always on an MVCC boundary? That would allow for  
> transactional replication of the form I'm talking about.

No it wouldn't, because some of the documents that it's about to read  
for previous updates might be updated again during replication.  
Transactions don't replicate. Never have.
>> For the new bulk transaction model, I'm only proposing supporting  
>> eventual consistency. All changes are safe to disk, but the db may  
>> not be in a consistent state right away.
> Or indeed, ever.

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.

>>> Not necessarily, and even if they did, it's likely that they'll  
>>> have multiple browser windows open.
>> What's the front end written in?
> On OSX, an Objective-C app that	provides an embedded Safari  
> connecting to an embedded Ruby/Merb admin server, although I'm  
> thinking of changing to Yaws et al. That provides a traditional OS  
> app, with a GUI that looks like iTunes, provided via HTML. The admin  
> app can then replicate/download web applications written in e.g.  
> Ruby (for now) which do the real work.

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.


> On Windows, something similar, I presume .NET/C++/Gecko. Discussed  
> in the contract RFI I posted.
> Antony Blakey
> --------------------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
> Human beings, who are almost unique in having the ability to learn  
> from the experience of others, are also remarkable for their  
> apparent disinclination to do so.
>  -- Douglas Adams

View raw message