---------- Original Message -----------
From: Paul Ruizendaal <pnr@...>

> Let's just stick with the four rules:
> 1. Stable view of data within a transaction
> 2. Cannot modify a record which has been modified in a commited concurrent
> transaction
> 3. Obeys consistency constraints within and across transactions
> 4. Ann's rule: same state on all nodes when quiesced
> So far I believe both your design and the Kemme design comply with the
> four rules. So a cloud database has to be ACID and SCOA :^)

------- End of Original Message -------

I would recommend you drop rule #2, and use rule #3 for it. Why? Because I see
there being two types of constraints: transitional and static. Static
constraints are what we usually talk about as needing to be satisfied at the
end of a transaction (or in the global database space, or after every
statement, depending). Transitional constraints are what people usually
implement with triggers -- a disallowed state change, despite the source and
destination states being individually allowed. I believe that rule #2 is
actually a form of transitional constraint, where multiple fields in a table
are required to move together. I can't quite formalize it, though. Maybe it's
really a third type, a conflict-resolution rule, independent of transitional
and static constraints. Be that as it may ...

Consider the following scenario:

transaction A: start
transaction B: start
transaction A: update accounts set name = 'Bob' where name = 'Larry';
transaction B: update accounts set balance = balance * 1.01;
transaction A: commit
transaction B: commit
(assume there's overlap between the two recordsets)

The fact that the fields are in the same table might not always immediately
imply that changes to one field are incompatible with changes to another. Yes,
you can split tables up (same pk, unique fk, whatever you need to do to keep
them synchronized) in order to fix this, but that's essentially a hack. What
you should be able to do is create a constraint that says that if 'name' is
modified, then 'balance' cannot be concurrently modified. Or that if 'status'
is set to 'closed', then 'balance' cannot be concurrently modified, but if it
changes from 'standard' to 'premium' then it can be, as so forth. I hate, for
example, that I can't tell CVS that in certain files, it's okay that two users
modified the file at the same time, because that chunk is an unordered list,
and simultaneous modification does not a conflict automatically make. (File or
record, the idea is the same.)

So maybe rule #2 shouldn't go away, but should be change to: conflict-
resolution rules must be satisfied. (Similarly: the 'name' field of 'accounts'
can be modified without putting a lock on the account record that prevents a
concurrent transaction from inserting into the 'transactions' table related to
it by FK -- which in FB is still a no-no today, and allows you to talk about
the problem without requiring you to talk about same-record modifications.)

-Philip