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.

[1] https://groups.yahoo.com/neo/groups/firebird-support/conversations/topics/111668

Aldo Caruso

 

> 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,

Ann