Paul Ruizendaal wrote:

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

A transaction 1 on node A may not "see" all updates that occurred before
it started. A transaction 2 on node B might have started, updated the
record, and committed, but the reports of some or all of these might not
have reached node A before transaction 1 started. This is OK because
the resolution agent is going to tell transaction 1 that transaction 2
beat him to the record. Like Firebird, transaction 1 then has to wait
for transaction 2 to be reported committed or rolled back. In this
case, transaction 2 committed, so transaction 1 has to report an update
conflict.

Yes, the resolution agents can be said to enforce serialization of
individual updates, but they don't force a serialization of transactions.

--
Jim Starkey
NimbusDB, Inc.
978 526-1376



[Non-text portions of this message have been removed]