Where should "@Transactional" post a Service Level or DAO

Question

Firstly, it’s possible that I’m asking for something that was already asked and answered before, but I could not get the search result. Well, in general (or always so far :)) We define transactional annotations at the service level. Typical spring sleep - this is usually

Controller-> Manager-> Dao-> Orm.

Now I have a situation where I need to choose between a domain model based on the client’s site. Let's say client A uses my domain model, everything is fine, but then another client site will provide me with a web service and will not use our domain model.

Which layer should I replace. I believe that this should be a DAO that will receive data from the web service and send it back to me. Those. two separately written DAO layers and connect depending on the scenario.

Now I realized that we are making a close connection (if there is such a thing or, say, does not have a weak connection) when we put @Transactional on the service level. So many brains cannot be wrong, or they (I doubt it).

So, the question "Where should the" @Transactional "" service level place or DAO be? "and this is the service layer down, I have to replace.

Answer 1

Ideally, a Service Level ( Manager ) represents your business logic, and therefore should be tagged @Transactional .

The service level can call different DAOs to perform operations with the database. Suppose you have 3 DAO operations in a service method. If your 1st DAO operation failed, the other two may still be skipped and you will receive an incompatible database state. The Annoating service layer can save you from such situations.

Answer 2

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

Answer 3

I will suggest putting @Transactional in service level methods, since we can have several DAO implementations. With this, we can make our services transactional. cm

It is recommended that you use a basic basic service to provide common services.

Service is the best place to place @Transactional, the service level should contain the behavior of the script using the level of detail for interaction with the user, which should logically occur in the transaction. in this way we can maintain a separation between web application code and business logic.

There are many CRUD applications that do not have any significant business logic; for them, having a service level that simply transfers data between controllers and data access objects is useless. In these cases, we can put the transaction annotation in Dao.

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

If you have multiple calls in your service, you need @Transactional in the service. different calls to the service will be made in different transactions if you enter @Transactional in the service.

Answer 4

This is an individual choice based on application types, if the application is multi-level in many modules, and most operations are based on @CRUD, and then adding @transactional annotations at the service level does more ... application type type, such as schedulers, task servers, @ etl report apps, where sessions and user concepts do not exist, then the propaganda transaction at the context level is most important ... we should not create clusterd transactions by setting @transactional every time we complete the transactional anti-pattern ... In any case, the pragmatic JTA2 transaction management is the most appropriate response ... again it depends on the weather, which you can use in certain situations ...

Answer 5

You must use @Transactional at the service level, if you want to change the domain model for client B, where you must provide the same data in a different model, you can change the domain model without affecting the DAO level by providing another service or by creating interface and implementation of the interface in different models and with the same service that fills the model based on the client. This decision is based on the business requirement and scope of the project.