Is it ever good practice to have non-transactional EJB "read" methods?

Question

This is a very humble question.

There are some articles that indicate that one should always use database transactions, even for simple read operations. Here is an arbitrary example that makes a lot of sense to me: http://nhprof.com/Learn/Alerts/DoNotUseImplicitTransactions The Hibernate documentation itself also says:

Always use clear transaction boundaries, even for read-only operations.

OK, seems clear enough. This has always been my assumption, viz. that since transactions are going to be applied implicitly at the database level anyway in all cases, it's probably better to always declare them explicitly.

Then I read other articles like this: http://www.ibm.com/developerworks/java/library/j-ts1/index.html#never (note the callout). This article says, in part:

Never say never

At certain times you may want to start a transaction for a database read operation for example, when isolating your read operations for consistency or setting a specific transaction isolation level for the read operation. However, these situations are rare in business applications, and unless you're faced with one, you should avoid starting a transaction for database read operations, as they are unnecessary and can lead to database deadlocks, poor performance, and poor throughput.

The bit about deadlocks and poor throughput also makes sense to me.

Conflicting advice at the lowest level. That's OK; as a humble application developer, I can make up my own mind here, I think: prefer the former advice, perhaps seeing if a given ORM/database combination achieves better performance without the transaction in certain performance-critical cases. Please correct me if I'm wrong.

Now I back up into the realm of the application server and XA transactions.

If I have an EJB method that does read-only operations, is it good practice to always declare it to be transactional (following the spirit of the Hibernate advice above)? Or does marking it as @TransactionAttribute(TransactionAttributeType.SUPPORTS) not imply much about the database transaction strategy down near the metal?

What I mean is, an EJB (JTA) transaction happens at the application server level. It may be the case (I don't know) that when a Java EE application server interacts with Hibernate that Hibernate will always enforce explicit database-level transactions, regardless of the application-server-level transaction policy in place. So the Hibernate-focused articles I've cited here may not apply to an application-server-level JTA transaction--perhaps it is good practice to mark read-only methods as @TransactionAttribute(TransactionAttribute.SUPPORTS) instead of REQUIRED.

What are people's thoughts here? All pointers--even to elementary information--are welcomed.

Answer 1

I see no problem in using TransactionAttribute.SUPPORTS, but you've gotta be sure about the context you're operating under.

What you're really saying is: "I don't care about dirty reads". Or phantom reads. The data you return to the user isn't guaranteed to be in a consistent state, and for a lot of applications, that's just fine.

Actually, I find that as enterprise developers we tend to overuse transactions. They have significant overhead. And your business case may actually be tolerant to showing some stale data in cases where the data read in isn't going to ever affect a write operation down the line.

In short, I think the EJB3 Tx annotations are each there for a purpose. If you understand their semantics and your application properly, you can make an informed decision as to what Tx mode is more appropriate.

S,
ALR