> Here is a first approximation of consistency rules:
>
> 1. A transaction sees a constant view of the database plus any
> updates performed by the transaction
> 2. A transaction cannot update or delete a version of a record that
> it could not see
> 3. Primary and unique keys must be guaranteed unique
> 4. Referential constraints must be honored
>
> What other elements of database consistency need to be maintained
> implicitly or explicitly?

If you use the above rules as the limits on keeping nodes consistent,
would it not lead to "lost update" issues?

E.g. two concurrent transactions, Tx1 registers a deposit of $10 in my
account, Tx2 a deposit of $20. Tx1 executes on Node A, Tx2 on node B. Tx1
commits first. When Tx2 commits, it updates its own record (it is
oblivious
to the other update under rule 2), the database remains consistent so the
commit proceeds. The Tx1 deposit is lost.

Probably you meant rule 2 as an optimistic lock (I did not read it that
way before). If that is the case, it should perhaps be phrased:

2. A transaction cannot update or delete a record that was concurrently
updated and committed in another transaction.

Paul