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

> The mechanism is that each record has a deterministic resolution agent.

> When initiates an update, it sends a message to the resolution agent
> requesting permission to perform the update. It is then free to make
> the tentative update locally, pending notification from the resolution
> agent. If the resolution agent detects a conflict, it refuses
> permission, and the local update must be backed out.

Okay, we're on the same page now.

> The different between this and Firebird is that each transaction sees
> the same version chain on the database page and a distinct resolution
> agent is not required.

Sure.

Rule No. 2 effectively says that conflicting writes are "consistently
ordered" by the resolution agent across nodes:
- the resolution agent accepts the update of a transaction A
- the resolution agent rejects update attempts of concurrent, conflicting
transactions e.g. B
- it has therefore ordered A before B and this ordering must be adhered to
on all nodes

Taking into account that a transaction should see all updates that
occurred before it started, there is also an implied causal order, but I'm
not sure yet that this should be the same on all nodes.

Paul