>So, somebody added read-committed to Firebird in order to make things
>less "confusing" and avoid having to explain that repeatable read is
>free if you have a versioning database.
>
>Around InterBase 6 and Firebird 1.0, a change was made so that
>read-committed transactions that are declared as read-only would not
>block garbage collection. That introduce a problem with blobs - if
>you're unlucky, you can read a record, get a blob id, and before you
>fetch the blob, another transaction could delete the record and commit,
>then some third transaction could garbage collect both the record and
>the blob. Then you'd get "blob not found" when you tried to open the
>blob. That's the reasonably good case. If you're more unlucky, some
>other transaction could have stored a record where that blob had been.
>Then you'd get a message saying that the database appears corrupt. If
>you're really unlucky, the slot where the blob had been would be used
>for a different blob, and you'd read something completely other than
>what you expected.
>
>Those problems can be avoided by not using the read-only option on
>read-committed transactions that look at blobs.
>
>So, my long answer - which is not even responsive to your question - is
>that read-committed isn't broken - it's just wrong.

These problems with blobs I remember being discussed at long on
Architect list... I didn't remember if a solution was found...