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