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
