I did go back and check the MySQL Falcon implementation. The mode is
supported only when Falcon is acting as a MySQL storage engine. Boolean
filtering is done in the MySQL engine, not Falcon, but Falcon does
filter for index retrieval. If either Falcon or the MySQL engine
recognized that a fetched record has not been presented to a client the
"unlock_row" storage handler method is called to undo any implicit
lock. So, yes, unintended consequences are undone at the SQL engine level.

The native Falcon engine doesn't recognize the "write committed"
transaction mode. The NimbusDB engine, however, does.

On 12/1/2010 12:11 PM, hvlad wrote:
>
> --- 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.

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