9

I am using Spring MVC with Hibernatedaosupport for my DAO classes. Confused here where to start the transaction, whether it should be in service layer or DAO layer?

My view interacts with Service layer. DAO's are injected into services.

What is the right way to use Spring MVC with Hibernate in DAO, service layer architecture?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Ramesh Kotha
  • 8,266
  • 17
  • 66
  • 90

3 Answers3

22

IMHO the transactions should go to service layer. Typically one business transaction consists of several queries and updates. If you place @Transactional only on DAO layer, each query and update will run in a separate transaction, which effectively defeats the purpose of transactions.

But if services are @Transactional, each database interaction joins one main transaction started when web layer entered the service layer. Note that in this case if web layer runs several service methods, each of them will run in a separate transaction (the same problem shifted one level up). But placing @Transactional in web layer might introduce unexpected side effects like N+1 problem, which would have been caught otherwise. Thus try to keep one business transaction in one service method called from web layer.

Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
  • Well I agree to @Tomasz except on using Transaction annotation on service layer and this is why... If I put transactional on service then my flexibility in the flow is broken there itself, I would prefer programmatic way of handling transactions just to keep my options open for selective transaction management. – Liam Jan 24 '12 at 20:36
0

There is a complete information for the Service layers, DAO layer, Entities and Controllers. It has full tutorial with short description for each module.

Site: Spring MVC With Hibernate CRUD

Or You may visit YouTube Channel: Spring MVC with Hibernate CRUD VIDEO

Muhammad Sadiq
  • 434
  • 4
  • 10
0

Obviously DAO layer. Anything that connects to data access layer should be in DAO layer and (preferably) annotated with @Repository and your service ( annotated with @Service) should have a handle to DAO instance.

A service can call multiple DAOs but not the other way round. DAOs should be atomic in nature.

If you are starting a transaction then it should be in service layer in my opinion which supports my previous statement where I mention DAOs should be atomic in nature.

Liam
  • 2,837
  • 23
  • 36
  • but if i start Transaction in DAO layer, i am getting two sessions opened exception or no session bound... becoz in service layer if i call two methods those two methods are using different sessions right.. then how to solve this.. – Ramesh Kotha Jan 24 '12 at 20:11
  • 1
    Why? That would require nested transactions for anything that goes through more than one DAO. – Dave Newton Jan 24 '12 at 20:12
  • Uh... "Obviously DAO layer" and "start transactions in the service layer". Those are mutually-exclusive. – Dave Newton Jan 24 '12 at 20:16
  • @hvgotcodes: I think I was editing my comment when you replied :) Can you proof read once more, if my assumption is correct ? – Liam Jan 24 '12 at 20:16
  • I still think this approach is incorrect, except perhaps in edge cases, and probably not. One logical unit of work might use multiple DAO calls. You want the transaction around all of them, not each one individually – hvgotcodes Jan 24 '12 at 20:17
  • 1
    No ! If you have transaction at service level, then you have more control over multiple DAO calls. Consider a scenario where you want transaction support over multiple DAOs which depend on each other, in that case the service is the right place to make that decision. If you have only one transaction mapped to DAO then you can very well do it easily in service layer. Its just gives more flexibility to play around and over that I don't believe DAOs to be linked with each other making them tightly coupled. – Liam Jan 24 '12 at 20:23
  • I simply love discussing this with great minds like you guys :) – Liam Jan 24 '12 at 20:25