Operation of the Spring Framework @Transactional

Question

1 - The Spring documentation describes the use of @Transactional Spring in the business rule classes(ProdutosService for example) there is some special reason to use this annotation in these classes instead of using DAO’s?

2 - The operation of the annotation @Transactional and the same of the use of the pattern Open Session in View? Otherwise, in which situations it is more interesting to use one instead of the other?

Answer 1

The annotation @Transactional demarcates transactions (you can start nested transactions, propagate transactions to other layers, etc.). The transaction is an isolated work unit that takes the database from one consistent state to another consistent state. Think in terms of business transactions yourself.

The recommendation for not demarcating the DAO layer but the business layer is due to the very nature and granularity of operations of each layer. Operations of the DAO layer usually have fine granularity (insert something, update something, consult something, etc). The business layer is thicker granularity, and can group various operations of the DAO layer (as well as other layers; e.g., JMS queues).

Bean de Negócio
  @Autowired BeanDAO1
  @Autowired BeanDAO2

  @Transactional  
  meu método de negócio() {
     consulta algo do DAO1
     faz um processamento
     insere algo no DAO2
     faz um update no DAO1
  }

See what business methods are good candidates for transactional "work units". The idea is that the work unit that takes the bank from one consistent state to another consistent state perform various operations. You want one of two things to happen:

1. the business method is successfully executed and a commit of everything be done
2. Any exception occurs, in this case a rollback shall be done for the previous state (as if none of the operations had taken place).

Now imagine that you wrote down the insertion method of DAO2 with @Transactional(propagation=Propagation.REQUIRES_NEW) (something that made sense in a certain piece of your application). If you do this your business method will no longer do rollback than was inserted into DAO2 (since the Insert happens in your own transaction). Imagine now that the update in the DAO1 failed and fired an exception; with this will be made a rollback that update, however the value inserted by DAO2 in the previous step will be maintained, potentially leaving your database in an inconsistent state. In this way it is good practice to make the DAO layer a mere "consumer" of transactions, and not an active agent of demarcations.

---

Open Session in view replaces transactional demarcation?

Not. Ok, I was a bit categorical here; but the truth is that if all transactions in your application have the same scope of the request (transaction-per-request) this is a strong indication that there is something wrong.

The purpose of the pattern Open Session in View (Osiv) is to facilitate the life of the programmer, allowing entities to be loaded in a lazy manner (Lazy) at render time of view (avoiding LazyInitializationException and similar).

<!-- Poderia disparar uma exceção se a sessão estivesse fechada -->  
#{minhaEntidade.listaDeOutrasEntidadesLazy}  

I’ve had several discussions about the pattern Osiv, I personally consider it an anti-standard, or at least a bad practice. While there are several advocates of the standard, I am not alone on the list of dissidents. Osiv is certainly useful and saves the programmer time avoiding that he has to worry about checking if the expected objects were correctly loaded. On the other hand, abusing this type of technique also stimulates the proliferation of various problems. Neglect of transactional demarcation is one of them, as well as problems of the type N + 1consultations.

Let’s say for example that your JPA provider has to make a query to retrieve each of the entities from a list Lazy, this will generate several selects unnecessary; something that could have easily been solved with a JOIN FETCH will potentially undetected for production due to the use of Osiv. At best Osiv acts as a safety net and hides the problem, in the worst case it creates an even bigger problem.

From the architectural point of view, long transverse sections end up tying the layers: exceptions of the data layer potentially affect the view, can happen at render time. From the point of view of performance Long-term sessions end up consuming more resources. From the point of view of reliability the standard ends up making room for unexpected failures, etc, etc, etc.

Anyway, as the subject is controversial, I make it clear that this is just my opinion.

Now about transactional control there is not much to discuss; your business methods must have well demarcated transactions according to the rules of your application. If eventually you want to use Osiv to carry something on view OK, but at this stage all business transactions must already have been committed. That is, one thing is business transactions with potentially destructive writing operations and another completely different is the session that is open on view for late loading of objects of a particular query.