Decided it was time to use something like Hibernate and recently ported an application over. Everything is working fine so far.

During a code review someone asked why aren't transactions used for things that don't write to the db. The simple answer is that originally it wasn't done that way in straight JDBC calls.

It has been pointed out that the suggested idiom does not make any distinction between reads and writes with the db. However, Hibernate managed transactions seem to interface with the cache. Maybe objects loaded into a transaction that gets rolled back are evicted.

I'd like to stress that we are not currently experiencing any problems with Hibernate but we'd like to know if there is anything extra that we aren't aware of.

Should we wrap all accesses to the db within a transaction?

Yes. Just because you didn't explicitely manage transactions for read-only calls with direct JDBC doesn't mean that there wasn't an autocomitted underlying "transaction" for a single statement.

Transactions are about isolation, not about "we don't manipulate data with a read operation". Another concurrent thread may alter data!

I'm still interested in the origin of the "reading data doesn't require transactions" myth. Who told you? :)

I wouldn't say anyone told me.

Hibernate additions aside, transactions can be used to join statements together into one unit and can be used to preserve a 'view' of data via levels of isolation.

The application concerned, collects fluid levels from sensors so the data is very simple. Multiple statements are joined together with a transaction because an averages table is updated for every new record. When reading takes place, as the data is effectively read-only (no records are ever updated) transaction isolation is not needed.

I appreciate that JDBC uses the automatic transaction per statement but from the API perspective there is nothing less than one statement of work. In effect, this operates directly on the db.

The original application talked directly to the db using ESLQ/C. I don't know what isolation levels were supported (Informix SE 5.0) but, from an application perspective, there was no chance for a dirty read.

The application was ported once to Java using JDBC and now to Hibernate. So, the answer to your question is, it's probably historic.

However, the reason for the original post was to determine if there was any extra trickery going on behind the scenes as part of the Hibernate additions to the transaction code which users should be aware of. For example, Hibernate managed transactions automatically perform a flush.