Spring declarative transaction: which is better AOP vs @Transactional support?

[manupriya.sinha]

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 -

PROS -
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.

CONS -
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

PROS -
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.

CONS -
1. This approach is invasive. Java code is coupled with transaction declaration.
2. Modifying transaction, code recompilation is required.

[Grzegorz Grzybek]

Hi

Good summary - it shows you're a great researcher - I like that attitude

My experience is that (referring to your points):

• In long term readability of code is one of the most important factors, so @Transactional in code is better than centralized configuration
• Centralized TX declaration has some benefits like fast view into what's transactional and what's not, but it's always easier to add @Transactional to new services than to fight with bugs after refactoring (e.g., package renaming)
• No code recompilation has no value - really. How many times have you changed Spring XML config without recompilation? We live in the era of maven/gradle and releasing new version is just a matter of another mvn/gradle command or one-click in Jenkins.
• PROS of AOP are just counterpoints of CONS in @Transactional and are not suitable in todays environments / processes.

So for TX Management I usually use @Transactional. Recently I had one use of AOP for TX - when I had two transaction managers - one for JTA (IBM FileNet) and one for Hibernate. @Transactional is used to demarcate JTA transaction, while Hibernate methods are AOP-demarcated (or explicitely use TransactionCallbacks).

Final point - don't be afraid of "coupling Java code with TX declarations" - you can always unit test your services by instantiating them with "new" - @Transactional is just annotation and requires someone who will make use of it.

regards
Grzegorz Grzybek

[manupriya.sinha]

Hi Grzegorz,

Thank you so much for clarifying. It helps.

-Manu

[Rober2D2]

So for TX Management I usually use @Transactional. Recently I had one use of AOP for TX - when I had two transaction managers - one for JTA (IBM FileNet) and one for Hibernate. @Transactional is used to demarcate JTA transaction, while Hibernate methods are AOP-demarcated (or explicitely use TransactionCallbacks).

Why use both @Transactional and AOP? In Spring 3 you may use the value attribute of @Transactional to tell the name of the transaction manager to use.

@Transactional(value="myJTATxManager")

@Transactional(value="myHibernateTxManager")

[Grzegorz Grzybek]

Why use both @Transactional and AOP? In Spring 3 you may use the value attribute of @Transactional to tell the name of the transaction manager to use.

@Transactional(value="myJTATxManager")

@Transactional(value="myHibernateTxManager")

Thanks - my problem was a bit different - one method is using both transaction managers (transactions are not coordinated with XA), so one transaction behaviour resulted from @Transactional and other - from TransactionTemplate.

regards
Grzegorz Grzybek