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
El 07/03/17 a las 15:52, Ann Harrison aharri...@ibphoenix.com
[firebird-support] escribió:
> On Mar 7, 2017, at 10:30 AM, Aldo Caruso aldo.car...@argencasas.com
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