On 08/02/2009, at 3:07 PM, Damien Katz wrote:
I can't see why this needs to be the case. The fact that there are
peers that have an incomplete replication doesn't stop the master
taking updates - iff the updates to the master are multi-document
ACID.
Because during downstream replication it may get just some of the
documents from a commit that happens during replication. Replication
isn't all or nothing, and it doesn't know about transactions
OK, I would have thought that a) replication was relative to a
specific MVCC commit; and b) a given user-level transaction was all
within a specific MVCC commit. So the replicator sees at least an MVCC
consistent view of the updates. Actually, I can't see how replication
that doesn't respect MVCC commits can work at all, because the
resultant data would be inconsistent with even the weaker ACID that
you've proposed.
The thing is, to avoid all conflicts and inconsistent states, you
must read lock the source db during active replication and write
lock the target database pretty much until the replication is
complete. Otherwise, you'll will get inconsistent states.
Locking for writes is obvious, but read locking the source isn't.
Does each user get their own local instance of the database?
Not necessarily, and even if they did, it's likely that they'll have
multiple browser windows open.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
The ultimate measure of a man is not where he stands in moments of
comfort and convenience, but where he stands at times of challenge and
controversy.
-- Martin Luther King
