Martijn Tonies wrote:

>>
>>In recent IB versions, read committed transactions don't block GC and this
>>is good. But they don't track blob references as this is not as good. So
>>there may be a moment of time when you have a blob id to fetch the blob
>>contents, but the blob is already garbage collected. As a result, you will
>>either get a runtime error or a wrong blob content, depending on whether
>>this blob id has been reused or not.
>
>
> What's the reason to re-use BLOB IDs?
>

A blob id is just a page number and an offset into the index on that
page. When a blob is released, the index entry is set to 0:0 - no
offset, no length - and is available for reuse as anything that can go
on a data page - record, fragment, back version, or blob.

I'd be tempted to go with the Borlandish solution - it will greatly
reduce the problems with blocked garbage collection - but the other is
not that hard.

Here's how I see it:

1) Change the lock data in the transaction lock for read-committed
transactions to 0 or -1 or some other easily recognized value.

2) When computing the oldest active, ignore that value.

- that's the Borland solution.

3) Create a new lock series for blob garbage collection - oldest_blob
for example.

4) At startup, read-committed transactions also take a lock in the blob
garbage collection series, identified by transaction id and containing
the current oldest-active as the data portion.

5) Add oldest_-blob to the header, transaction, and database structures.

6) At startup, every transaction gets the oldest_blob value.

7) In garbage collection, notice whether the record has blobs. If so,
check both oldest_active and oldest_blob before removing old versions.

Those steps will eliminate a current bug - that from time to time
read-committed transactions get an inexplicable "Blob not found".


Regards,

Ann