Menu
I am bit of unclear about the usage of @Transactional annotation in the business/service layer.
My question is, when used together with ISOLATION_SERIALIZABLE in business layer, does the @Transactional annotation guaranty that no concurrent access is allowed to the particular method?
@Transactional(isolation = Isolation.SERIALIZABLE)
public void businessMethod() {
// calls subBusinessMethod
subBusinessMethod();
---------------
---------------
---------------
}
Imagine that subBusinessMethod calls to the DAO layer to do some db transactions. The code execution(more db calls may be) after the call to subBusinessMethod depends on the result of the db transaction took place in subBusinessMethod.
I need to make sure that the subsequent calls to the businessMethod should not call the dao layer to read/write from/to the database without knowing what happened to the db tables from previous calls. Required validations have been added in the business logic.
First of all, is my approach valid? If so, am I using it in the correct way. ?
644
The @Transactional annotation makes use of the attributes rollbackFor or rollbackForClassName to rollback the transactions, and the attributes noRollbackFor or noRollbackForClassName to avoid rollback on listed exceptions. The default rollback behavior in the declarative approach will rollback on runtime exceptions.
As most of you probably know, due to the very nature of the solution, Spring's @Transactional annotation does not work on private methods unless you're using the AspectJ mode (which, in my experience, most of us aren't).
The @Transactional annotation belongs to the Service layer because it is the Service layer's responsibility to define the transaction boundaries.
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 ...
No. The @Transactional attribute maps directly down to the database level. The method can and will be accessed concurrently (only synchronized or other locking can prevent that).
The underlying database transactions on the other hand will be executed with serializable isolation, i.e. the end results of the transactions must be as if each transaction were run one after another (even if they weren't really run one after another).
Based on your requirements, it seems that this is a viable approach. But it may not be the only or even the best one.
169
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
