Question

I have an application which uses Spring 2.5 and Hibernate 3.

There’s a web application with a presentation layer, a servive layer and a DAO layer, as well as some Quartz jobs sharing the same service and DAO layers.

Transactions are initialized in different layers with @Transactional annotations, like this:

It led me to a problem I described here: Controlling inner transaction settings from outer transaction with Spring 2.5

I read a bit about how to set-up transactions to wire Spring and Hibernate together. It looks the recommended approach is to initialize transactions in the service layer.

What I don’t like is that most transactions exist only because they are required for hibernate to work properly.

And when I really need a transaction for a job calling multiple service methods, it seems I don’t have a choice to keep initializing transactions from the jobs. So moving @Transactional annotations from DAO to service doesn’t seem to make any difference.

How would you recommend to set-up transactions for this kind of application?

Answer 1

I read a bit about how to set-up transactions to wire Spring and Hibernate together. It looks the recommended approach is to initialize transactions in the service layer.

Definitely. Transaction demarcation should be done at the service layer level, not at the DAO layer level:

• the unit of work is the service, not the DAO
• you want a transaction to span multiple DAOs if required.

What I don’t like is that most transactions exist only because they are required for hibernate to work properly.

You should maybe elaborate this part because transactions are not Hibernate specific.

And when I really need a transaction for a job calling multiple service methods, it seems I don’t have a choice to keep initializing transactions from the jobs.

If you want to call multiple services inside a transaction initiated from the Job layer, declare your services as transactional with REQUIRED semantics (the default) and rely on Spring transaction propagation (this applies unless you need a remote call; in that case, use EJBs).

So moving @Transactional annotations from DAO to service doesn’t seem to make any difference.

It does make a difference and the fact that you need to initiate transactions from the Job layer when running batches doesn’t make things different.

I warmly recommend to read the Chapter 9. Transaction management.

---

(…) my main problem comes from Hibernate. Sorry if I wasn’t clear.

No problem. It’s just that when a question is vague, you often get a vague answer 🙂

From hibernate documentation: “Database transactions are never optional. All communication with a database has to occur inside a transaction.”. That’s why developers put DAO methods transactional on my project.

Sorry but the above statement only says that the “communication with a database has to occur inside a transaction”, nothing more, and deciding where to start transaction is left at your discretion (typically the service layer). If you do it at the DAO level, what if MySuperService calls DaoFoo and DaoBar and DaoBar fails? In such cases, you’ll probably want to rollback all the changes, not only those performed in DaoBar. Hence the need to control transaction where the unit of work starts.

IMHO, the developers need some guidance.

Does that mean all my services should be transactional? Even when I just read data for example?

First of all, I suggest to read Non-transactional data access and the auto-commit mode (the little brother of Sessions and transactions) to clarify things about “read-only transactions”. Reading the whole page is worth it but let me just quote this specific part:

Many application developers think they
can talk to a database outside of a
transaction. This obviously isn’t
possible; no SQL statement can be send
to a database outside of a database
transaction. The term nontransactional
data access means there are no
explicit transaction boundaries, no
system transaction, and that the
behavior of data access is that of the
autocommit mode. It doesn’t mean no
physical database transactions are
involved.

Once you’ll be done with the above link, the next suggested reading will be @Transactional read-only flag pitfalls. Here is the relevant part:

(…) The bottom line is that when you
use an ORM-based framework, the
read-only flag is quite useless and in
most cases is ignored. But if you
still insist on using it, always set
the propagation mode to SUPPORTS, as
shown in Listing 9, so no transaction
is started:

Listing 9. Using read-only and SUPPORTS propagation mode for select
operation

@Transactional(readOnly = true, propagation=Propagation.SUPPORTS)
public TradeData getTrade(long tradeId) throws Exception {
   return em.find(TradeData.class, tradeId);
}

Better yet, just avoid using the
@Transactional annotation altogether
when doing read operations, as shown
in Listing 10:

Listing 10. Removing the @Transactional annotation for select
operations

public TradeData getTrade(long tradeId) throws Exception {
   return em.find(TradeData.class, tradeId);
}