Vladislav Vaintroub wrote:
>
>> -----Original Message-----
>> From: Kevin.Lewis@stripped [mailto:Kevin.Lewis@stripped]
>> Sent: Wednesday, January 21, 2009 5:42 PM
>> To: Jim Starkey
>> Cc: Christopher Powers; Ann W. Harrison; FalconDev
>> Subject: Re: When you have a chance...
>>
>> > Jim Starkey wrote:
>>
>>> Kevin, let's rethink this. In the original design, this wasn't an
>>>
>> issue
>>
>>> because the only transaction that would look at the data was in the
>>>
>> same
>>
>>> thread as the chill, so no race condition could occur. Did I miss
>>> something, or did something change that made this assumption
>>>
>> unwarranted?
>>
>> Jim,
>>
>> I think that Table::checkUniqueRecordVersion() and
>> Index::duplicateKey()
>> called from Index::garbageCollect() have always needed to traverse the
>> whole record chain looking at the data buffer if it exists. These
>> functions are separate threads than the one doing the chilling.
>>
>> The former must look to see if there is a duplicate conflict with ANY
>> record old, active, or pending.
>>
>
> Interesting, I still do not get it, why we checking for uniqueness during
> garbage collection? We have no possibility to report an error to user at
> this stage.
>
>
>
>
We need to determine whether an index node for a departing record needs
to be deleted. If the value is represented in a record version that is
hanging around, we don't need to remove the node from the index.
Otherwise, we do.
The same problem (and solution) applied to blob garbage collection.
--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376
