Spring @Transactional Annotation Best Practice

Question

We are currently discussing the Best Practice for placing the @Transactional annotations in our code.

Do you place the @Transactional in the DAO classes and/or their methods or is it better to annotate the Service classed which are calling using the DAO objects? Or does it make sense to annotate both "layers"?

Answer 1

I think transactions belong on the Service layer. It's the one that knows about units of work and use cases. It's the right answer if you have several DAOs injected into a Service that need to work together in a single transaction.

Answer 2

The normal case would be to annotate on a service layer level, but this really depends on your requirements.

Annotating on a service layer will result in longer transactions than annotating on DAO level. Depending on the transaction isolation level that can youse problems, as concurrent transactions wont see each other's changes in eg. REPEATABLE READ.

Annotating on the DAOs will keep the transactions as short as possible, with the drawback that the functionality your service layer is exposing wont be done in a single (rollbackable) transaction.

It does not make sense to annotate both layers if the propagation mode is set to default.

Answer 3

Transactional Annotations should be placed around all operations that are inseparable.

For example, your call is "change password". That consists of two operations

1. change the password
2. audit the change
3. email the client that the password has changed

So in the above, if the audit fails, then should the password change also fail? If so, then the transaction should be around 1 and 2 (so at the service layer). If the email fails (probably should have some kind of fail safe on this so it won't fail) then should it roll baack the change password and the audit?

These are the kind of questions you need to be asking when deciding where to put the @Transactional.

Answer 4

Also, Spring recommends only using the annotation on concrete classes and not interfaces.

http://static.springsource.org/spring/docs/2.0.x/reference/transaction.html

Answer 5

It is better to have it in the service layer! This is clearly explained on one of the article that I came across yesterday! Here is the link that you can check out!

Answer 6

I was getting error while doing the transaction in my code. Thanks to this discussion I was able to resolve it.

Answer 7

The correct answer for traditional Spring architectures is to place transactional semantics on the service classes, for the reasons that others have already described.

An emerging trend in Spring is toward domain-driven design. Spring Roo exemplifies the trend nicely. The idea is to make the domain object POJOs a lot richer than they are on typical Spring architectures (usually they are anemic), and in particular to put transaction and persistence semantics on the domain objects themselves. In cases where all that's needed is simple CRUD operations, the web controllers operate directly on the domain object POJOs (they're functioning as entities in this context), and there's no service tier. In cases where there's some kind of coordination needed between domain objects, you can have a service bean handle that, with @Transaction as per tradition. You can set the transaction propagation on the domain objects to something like REQUIRED so that the domain objects use any existing transactions, such as transactions that were started at the service bean.

Technically this technique makes use of AspectJ and . Roo uses AspectJ inter-type definitions to separate the entity semantics (transactions and persistence) from the domain object stuff (basically fields and business methods).