|Subject||Re: [firebird-support] Read Only Transaction|
On Mar 8, 2017, at 7:17 AM, Aldo Caruso aldo.caruso@... [firebird-support] <email@example.com> wrote:
Thanks for your answer.
Regarding the "blob not found" error, there is a thread about this issue 
Nevertheless, I believe that RO/RC transactions are assigned a unique ID, because as I start them the next transaction ID keeps incrementing.
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.