I've read other forum posts and emails from the developers' mailing list that indicate it should be a best practice to wrap all data operations within a transaction block or use a form of declarative transaction management. This is suggested for read only queries as well. I have no problem doing this but it does have a performance impact. The performance implications that I see are this:

- 2 small statements issued to the database to begin the transaction and commit the transaction. Granted these are very small statements, but its still sent over the wire to the database as separate communications outside of the actual query statement.

- If the transaction is committed, NHibernate will attempt to flush the session. You can avoid this hit by rolling back the transaction since its a read only query but I find this to be very unintuitive when looking at the codebase. Also rolling back a succesfull query with declaritive transaction management is not very pretty at all.

So in theory, wrapping all data operations within a transaction sounds great, but considering the extra baggage that comes along with it, is it really worth it? Are most devs out there wrapping thier read only operations in a transaction block? I'm very interested in getting some experienced feedback on this.

Thanks.

So am I to assume that nobody is using Transactions for read only queries?

I definately do not.



Now, depending on your situation, if you're hitting SQL 2005 and using System.Transactions then, as long as you're not explicitly opening a transaction in NHibernate, it should stay as a lightweight transaction and not promote to a DTC-managed transaction.

That's probably the biggest performance hit in your scenario, promoting to the transaction manager for your given database platform...

Thats pretty much what I thought. I assume most devs arent using transactions for read only queries. Yet, Hibernate in Action reccomends that you should use transactions for read-only queries. Actually they have a FAQ on page 159 that asks:

Is it faster to roll back read-only transactions? The book states that they have failed to find any source of real numbers showing a performance difference.

This may be true on the database side, but it isnt true on the Nhibernate side sents a flush wil be performed if the default flush mode is commit.

Performance vs best practices seem to always conflict with each other.