Question

A while back I wrote an application which used Spring AOP for defining which methods were transactional. I am now having second thoughts as to how much of a great idea this was; I have been hit a few times after a minor refactor (changing method signatures etc), which of course doesn’t become apparent until something actually goes wrong (and I have a logically inconsistent database).

So I’m interested in a few things:

1. Have other people decided to revert to explicit transaction management (e.g. via @Transactional annotations)?
2. Are there useful tools I can use as part of a build process to help identify whether anything has been ‘broken’?
3. If people are using AOP to manage transactions, what steps are they taking to avoid the mistakes I’ve made?

I’m using IntelliJ IDEA which allows you to browse decorated methods and will refactor Spring XML config together with method name changes, but this is not always sufficient (adding a parameter to a method in the wrong place can affect whether an aspect fires for example)

Answer 1

I am currently using declarative transaction management in the two Java projects I work on, specifying which methods need transactional scope with @Transactional annotation. In my opinion, it is a good mix of flexibility and robustness: you are able to see which methods have transactional behavior via a simple text search, can adjust isolation and propagation attributes by hand if needed, and the additional amount of typing is practically negligent.

On one of those projects, I have security/logging implemented via aspects and have occasionally stumbled on same obstacles you when renaming a method or changing signatures. In the worst case, I lost some logging data of user accessing contracts, and in one release, some user roles were not able to access all application features. Nothing major, but, as far as database transactions go, though, I think it’s simply not worth it, and I it is better to type @Transactional bit yourself. Spring does the hard part, anyway.