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