> Jim Starkey wrote:
> Is hasData() the same as hasRecord()?
Yes, sorry, I was using a non-existant term. I meant hasRecord()
> If the actual deletion of the record data were deferred until after the
> current cycle, the pointer would remain valid. It delays the
> reusability of the memory, but is near infinitely faster than taking a
> lock and releasing a lock on every record fetch cycle.
> RecordVersion::thaw might even try to fetch the purged data back from
> the purgatory (anyone have a better word? It certain is the the obvious
> name for something where things waiting to be purged to be put.)
Well, yes, it looks like cycle locking can be used to safely send a
records data buffer and pointer to purgatory. And as you say, it may
have the advantage of being able to 'redeem' a data buffer during a
thaw, if it is not too late!
I think that hasRecord() will need to return the pointer that it
validates because the chill may zap that pointer immediately after.
Maybe, this approach can also be used when separating DeferredIndexes
and Transactions. Or as well as an Index from its Table.
But we do not have time this month to implement this solution. So we
will keep it in the plans for the future. Chris will open a worklog for
it. It should fit very well into the performance release effort where
we are trying to clean up high concurrency blockages.