There seem to be very different opinions about using transactions for reading from a database.
Quote from the DeveloperWorks article Transaction strategies: Models and strategies overview:
Why would you need a transaction if
you are only reading data? The answer
is that you don’t. Starting a
transaction to perform a read-only
operation adds to the overhead of the
processing thread and can cause shared
read locks on the database (depending
on what type of database you are using
and what the isolation level is set
to).
As a contrary opinion there is the following quote from Hibernate documentation Non-transactional data access and the auto-commit mode
Our recommendation is to not use the
autocommit mode in an application, and
to apply read-only transactions only
when there is an obvious performance
benefit or when future code changes
are highly unlikely. Always prefer
regular ACID transactions to group
your data-access operations,
regardless of whether you read or
write data.
There is also a similar debate on the EclipseLink mailing list here.
So where lies the truth? Are transactions for reading best-practice or not? If both are viable solutions, what are the criteria for using transactions?
As far as I can see it only make a difference if the isolation level is higher than ‘read committed’. Is this correct?
What are the experiences and recommendations?
Steven Devijver provided some good reasons for starting transactions even if the operations are only going read the database:
Standard SQL requires that even a query must start a new transaction if there is no transaction currently in progress. There are DBMS where that is not what happens – those with an autocommit mode, for example (the statement starts a transaction and commits it immediately the statement completes). Other DBMS make statements atomic (effectively autocommit) by default, but start an explicit transaction with a statement such as ‘BEGIN WORK’, cancelling autocommit until the next COMMIT or ROLLBACK (IBM Informix Dynamic Server is one such – when the database is not MODE ANSI).
I’m not sure about the advice never to rollback. It makes no difference to the read-only transaction, and to the extent it annoys your DBAs, then it is better to avoid ROLLBACK. But if your program exits without doing a COMMIT, the DBMS should do a ROLLBACK on your incomplete transaction – certainly if it modified the database, and (for simplicity) even if you only selected data.
Overall, if you want to change the default behaviour of a series of operations, use a transaction, even if the transaction is read-only. If you are satisfied with the default behaviour, then it is not crucial to use a transaction. If your code is to be portable between DBMS, it is best to assume that you will need a transaction.