Steven Devijver provided some good reasons for starting transactions even if the operations are only going read the database:
- Set timeouts or lock modes
- Set isolation level
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.