--- In Firebird-Architect@yahoogroups.com, Jim Starkey wrote:

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

Thanks. This is almost equal to the my second example. BTW, first example is how SELECT WITH LOCK implemented in Firebrid.

Regards,
Vlad