Subject Re: [firebird-support] Read Only Transaction
Author Ann Harrison

On Mar 8, 2017, at 7:17 AM, Aldo Caruso aldo.caruso@... [firebird-support] <> wrote:

Thanks for your answer.

Regarding the "blob not found" error, there is a thread about this issue [1]

Nevertheless, I believe that RO/RC transactions are assigned a unique ID, because as I start them the next transaction ID keeps incrementing.

Right. They're precommitted but do get unique ids.  I'm getting old  




Aldo Caruso

El 07/03/17 a las 15:52, Ann Harrison aharrison@... [firebird-support] escribió:

> On Mar 7, 2017, at 10:30 AM, Aldo Caruso aldo.caruso@... wrote:

> Supposing a connection only needs to read from a database. Which are the benefits of starting a read only transaction ?
I doubt that there is any difference in performance that you could measure. Almost all transactions change the database - cooperative garbage collection, incrementing the next transaction id on the header page, ending the transaction on the TIP. The security checks have to be made to insure read access - checking for higher levels is no more expensive. DEclaring a transaction to be read-only is a slight check on programmers - Firebird will detect and block writes that were added carelessly in a point version of an application.

However, a read-only, read-committed transaction has merit if you don't need consistency. Firebird doesn't assign a unique transaction id to RO/RC transactions, so they don't change the next transaction id, they don't block garbage collection, and they don't change the state of a bit on a TIP. From time to time (IIRC) they'll return a "blob. not found" error if the record holding the blob is garbage collected between the time the RO/RC transaction reads the record and retrieves the blob.

Basically, read-only was implemented decades ago to give InterBase a check mark on standard compliance and Firebird added a hack to provide low overhead, low consistency transactions.

Good luck,