On 11/30/2010 6:35 PM, hvlad wrote:

>
>> The algorithm is simple, though the details might not be. When a record
>> is fetched "for update" in write committed mode:
>>
>> 1. Look at the head record version. If the transaction that created
>> it is committed, do a dummy update and return.
> Is this dummy update made when page is locked for fetch ?
>
> I mean, what is exact order of events :
>
> fetch page for read
> extract record
> release page lock
> validate booleans
> fetch page for write
> create stub
> release page lock
> return record to caller
>
> or
>
> fetch page for write
> create stub
> extract record
> release page lock
> validate booleans
> return record to caller
>
> or may be something else ?
>

NimbusDB doesn't have pages and record versions in Falcon exist only in
memory, so I'm afraid I'm going to have to say "none of the above".

That said, the lock operation is quite close to a Firebird record
deletion, so the order of battle would need to be something like:

* Fetch page for write
* Examine record version; if necessary, release page and wait for
transaction to commit or rollback
* Create stub
* Release page
* Validate booleans (we're back in the RSB world, again)
* Return record to caller (or whatever)

I'd have to go back to the code and check, but almost all of this would
be at VIO level in Firebird / Interbase (RIO in Rdb/ELN).


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



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