I want to understand -
1. Are there use cases where one approach is preferred over another (AOP vs @Transactional)?
2. Are there any best practices around the declarative transactions?
I understand declarative transaction support is made possible with Spring AOP. So whether I implement transaction using AOP directly (Advice, point-cuts etc.) OR I implement it using @Transactional annotation - Spring generates AOP proxies in both these cases.
As per my understanding, some PROS and CONS with both these approaches ->
I. Using AOP directly -
1. Java code is cleaner and any transaction configuration is declared outside the code, in configuration files.
2. Transaction is centralized at one place.
3. No code recompilation is required on modifying transactions.
1. Developers need to understand AOP concepts to manage transactions effectively.
2. Because transactions are defined outside the code, it is difficult for developers to understand from code which methods are in transaction and which are not.
3. Even for a small data access operation, developers need to modify java code as well as configuration files.
4. When modifying or re-factoring java code, developers need to be careful if that impacts existing transaction declaration in any way (point-cuts etc.).
For example, changing the method name can potentially move a method in or out of transaction.
5. Transaction is one of the core requirements for any application. With this approach even a small modification to declarations can sneak in hard-to-find bugs.
6. Testing scope is higher - even for a minor modification to existing transaction declarations, we will need regression for the complete declaration scope.
II. Using @Transactional annotation
1. Transaction declaration is inline with java code, code readability is better.
2. With @Trasactional, developers will more aware of transaction flow while modifying/re-factoring code.
3. Testing scope is limited to newly added/modified methods only. The other other methods in the same class remain unaffected.
1. This approach is invasive. Java code is coupled with transaction declaration.
2. Modifying transaction, code recompilation is required.