buppcpp wrote:

> I have read that "read commited" should not be used, because it
> is "broken".

It's not broken, it's just not a transaction mode that a serious
database type could love. The C in ACID is Consistency, meaning that if
you read a record twice, you'll get the same answer both times - reads
are repeatable. That can be managed in one of two ways, blocking
updates to records you've read, or keeping your copy around as a back
version behind new updates.

The first method, blocking updates to records that have been read by an
active transaction is the most common implementation. It has exactly
the effect you would expect - a major report stops all other operations.
People hate it.

The second method, used by InterBase, Firebird, Postgres, and an
increasing number of commercial databases, allows readers and writers to
coexist happily. It has two problems. First, everybody knows that
repeatable read is really expensive, so non-repeatable reads have to be
an optimization. Untrue, but well-known. Second, two people sitting
next to each other, running transactions that started at different times
see different data. This is "confusing."

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.


Cheers,


Ann