Paul Ruizendaal wrote:

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

No, that's covered by the rule that a transaction can't update a version
of a record that it didn't / couldn't see. In other words, a classical
Firebird update conflict.

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.

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

I'll answer your other email when the dog stops barking.

Incidentally, next Friday is Ann's last day at MySQL / Sun /Oracle.

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



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