Subject Re: [Firebird-Java] 335544329 invalid BLOB ID
Author Jim Starkey
Roman Rokytskyy wrote:

>>No, happily this isn't possible. Blobs are garbage collected when the
>>parent records are deleted or have versions pruned. And the symptom
>>would only be visible from a read committed transaction and then only
>>between the interval of fetching a record and having it deleted and
>>garbage collected. A transaction containing an insert wouldn't meet any
>>of these conditions, let alone all of them.
>Even if we talk about "INSERT INTO ... SELECT * FROM aTable"? So, if we have
>READ COMMITTED isolation and engine fetches the record including the BLOB ID
>and before the record is written, parent is deleted and BLOB is garbage
>collected. Can this happen?
I suppose. The problem is that I can't image someone doing an update
based on a read committed transaction -- the result would be cascading
garbage. But I suppose is someone were foolish enough to do that, it's
possible to get that error. But if it's reproduceable, it's something else.

To editorialize a bit, read committed transactions are a really bad idea
and should never have been implemented and should never be used for
anything other than a monitoring tool, and then not even then. They
were invented as work arounds for database systems that have unuseable
concurrency control. They violate everything this is holy about
database theory and practice. Anyone -- and I pick my words carefully
-- who designs an application around read committed transaction has
almost certainly committed a very serious design error. Databases are
designed to provide a consistent basis for decision making. A
concurrency model that doesn't give consistent results is not suitable
for real applications. I invented multi-generational concurrency
control to get around the implications of two phase record locking.
People should understand it and use it. A transaction should give
consistent results, always, or die trying. If you want to get a newer
snapshot of the database, start a new transaction.


Jim Starkey
Netfrastructure, Inc.
978 526-1376