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

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)?

In my opinion it depends on the requirements of the use case you are implementing. If non repeatable reads and/or phantom reads are tolerated, your read-only method is not required to be always ran inside a transaction. For some types of searches or report generation tasks this is acceptable. On the other hand think about a situation like this:

List<Post> posts = findAllPosts();
for (Post p : posts) {
  Statistics s = findStatisticByPostId(p.id);
  doSomethingWithStatistics(s);
}

In such a case, it’s possible for one post to have its statistics returned by the time T1, and the other one by the time T2, where T2 > T1, as each call to findStatisticByPostId will be ran inside its own transaction. And it is possible for both of the posts to have seen some statistics during (T1...T2).

So if you generate a report according to the returned Statistics objects, it is not possible to guarantee that the report is based on all the statistics that have been available by the time T2.

Again depending on the requirements of what your are trying to implement, this is sometimes acceptable and sometimes not.