Where should "@Transactional" be placed Service Layer or DAO

Question

Firstly it is possible that I am asking something that has been asked and answered before but I could not get a search result back. We define transactional annotations on service layer typical spring hibernate crud is usually

Controller->Manager->Dao->Orm .

I now have a situation where I need to choose between the domain model based on client site. Say client A is using my domain model all is good but then an other client site would give me a web service and not be using our domain model.

Which layer should I be replacing . I believe it has to be DAO which will be getting me data from web service and sending it back.i.e two separately written DAO layers and plugged in based on scenario.

I have now realized that we have been doing tight coupling (if there is such a thing or say not having loose coupling) when we put @Transactional in Service layer. So many brains can not be wrong or are they (I doubt it).

So question is "Where should "@Transactional" be placed Service Layer or DAO ?" and is it service layer downwards I should be replacing.

---

Eleven years on and still relevant . If I look back at the project somethings were obviously wrong with my understanding of Domain model back then . I was regarding ORM layer as domain model and we wanted to work with ORM and detached entities and no have any data mapping and not have any DTOs. That was the trend those days. These days Domain Model is not the ORM and having a proper Domain model and using ORM or Webservices are datasources take care of this issue. Like many pointed out yes Service is the right place for it and have proper domain model and not regard JPA (ORM) as domain model.

Cooperman

This question is actually a duplicate of Spring @Transactional Annotation Best Practice. – Mitran

Answer 1

Ideally, Service layer (Manager) represents your business logic and hence it should be annotated with @Transactional.

Service layer may call different DAOs to perform DB operations. Lets assume a situation where you have 3 DAO operations in a service method. If your 1st DAO operation failed, other two may be still passed and you will end up with an inconsistent DB state. Annotating Service layer can save you from such situations.

Journeyman

Thanks for your reply. Can you please state the year you replied ? Believe it or not I think you might have just proved existence of time machine. Gave you +1 in 2015. – Cooperman

I didn't notice the year until you asked :) – Journeyman

Answer 2

You are going to want your services to be transactional. If your DAOs are transactional, and you call different DAOs in each service, then you would have multiple transactions, which is not what you want. Make the service calls transactional, and all DAO calls inside those methods will participate in the transactions for the method.

Antimasque

couldn't he specify a Propagation method on his @Transaction annotation, so that only 1 transaction is used, as it is listed here – Favouritism

@FotisParaskevopoulos That would work only if he has @Transactional on both the service and the DAO. Then the extra annotation won't hurt, but won't help either. – Wimberly

Answer 3

i will suggest to put @Transactional in Service layer methods since we can have multiple DAO implementations. by using this we can made our services will be transactional. refer

best practice is to use A generic BasicService to offer common services.

The Service is the best place for putting @Transactional, service layer should hold the detail-level use case behavior for a user interaction that would logically go in a transaction. in this way we can have maintain separation between web application code and business logic.

There are a lot of CRUD applications that don't have any significant business logic, for them having a service layer that just passes stuff through between the controllers and data access objects is not useful. In these cases we can put transaction annotation on Dao.

So in practice you can put them in either place, it's up to you.

By having multiple calls in your service you need @Transactional in service. different calls to service will execute in different transactions if you put @Transactional in service.

Astronaut

Answer 4

It's of a personal choice based on application types, if application is layerd across many modules and majority of operations are @CRUD based ,then having @transactional annotation at service level makes more sence.. engine type application like schedulers , job servers,@etl report apps, where sessions and user concept does not exists, then propagational transaction at context level is most suitable... we should not end up creating clusterd transactions by putting @transactional every where ending up transactional anti patters...anyways for pragmatic transaction control JTA2 is most suitable answer...again it depends on weather you can use it in a given situations...

Sanskritic

Answer 5

You should use @Transactional at service layer, if you want to change the domain model for client B where you have to provide the same data in a different model,you can change the domain model without impacting the DAO layer by providing a different service or by creating a interface and implementing the interface in different model and with the same service populate the model based on the client.This decision is based on the business requirement and the scope of the project.

Woolly

Answer 6

We should use @Transactional only if we have to manipulat data between multiple database or table or repositories, service should rollback transaction if one repository faild to insert data for exemple, in this case i think it's best practices to add @Transctional on services level.

but we wi never add @Transactional on Controller level !

Fiji

Answer 7

One more perspective that is important before making a decision is if the service layer has no network calls (or any slow-running task), then the service can annotated with @Transactional.

Q: Why does this matter?

A: The answer is that when you execute a DB query, the DB thread is kept on hold until the transaction is either committed or rollbacked. So when executing a slow task (like a network call), the DB thread is on hold unnecessarily making the overall system less scalable.

Q: But how does the system become less scalable?

A: Consider a high-scale system where you continuously need a DB thread to pull in some data from DB, but if DB threads are kept on hold, the pool quickly gets exhausted making no thread available for other calls to execute DB queries.

Barneybarnhart

When you say DB thread, do you mean a DB connection? – Hindsight

Answer 8

i have heard in a programming class,that dao layer is responsible for interacting with database, and service is a set of operations might be with dao and therefore database or not and that set of operation is in one transaction, mean is better service be transactional.

Berner