On 08/02/2009, at 2:17 AM, Damien Katz wrote:
1. Transactions don't work with replication. Replication doesn't
repeat the bulk single transaction, it just copies the documents
individually to the target replica. This means any downstream
replica can and will sees inconsistent states until replication
fully completes, not "all or nothing" states. With bidirectional
replication is even worse, as you can get edit conflicts that must
be resolved by an external process, .
This presumes that the UI model doesn't distinguish between conflicts
due to replication and constraint failures due to local ACID operations.
In my Notes Client-like model for example:
1. Web actions such as form submits don't result in conflict - they
either succeed or fail, to be retried. Users don't want to be thrown
into a conflict resolution UI when they hit save on a document that
they've been editing for some time.
2. Replication and normal operation are exclusive states. The
replication process checks for conflicts, and won't re-enter the
normal operational state until conflicts are resolved by the user,
using a specialized replication-conflict UI.
In my model, conflicts only ever occur due to replication, and this
fact allows applications to be considerable simpler, and the user
experience to be IMO vastly superior.
2. Transactions don't work in a partitioned database without a huge
performance hit (locking + 2 phase commits).
Can you share your thinking about your model for a partitioned
database? For example: are there any consistency guarantees or ACID
constraints (e.g. storage) within the cluster? Is there actual or
effective serialization of updates on a cluster-wide basis? Are views
cluster-wide?
I really need to know more about your model before I can reason about
this point.
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
