We currently put the @Transactional annotation onto our service interfaces. Spring apparently does not recommend this.
The Spring team's recommendation is that you only annotate concrete classes with the @Transactional annotation, as opposed to annotating interfaces. You certainly can place the @Transactional annotation on an interface (or an interface method), but this will only work as you would expect it to if you are using interface-based proxies. The fact that annotations are not inherited means that if you are using class-based proxies (proxy-target-class="true") or the weaving-based aspect (mode="aspectj") then the transaction settings will not be recognised by the proxying/weaving infrastructure and the object will not be wrapped in a transactional proxy (which would be decidedly bad). So please do take the Spring team's advice and only annotate concrete classes (and the methods of concrete classes) with the @Transactional annotation. –
If we move the annotations to the concrete service implementation classes we will fall in line with Spring. We might also solve the problem of transactions not rolling back across service method calls.
Step #1 of this ticket is to write a unit test that shows that if two service methods are called (one from inside the other) the first one will not be rolled back if there is an error during the second one. (Ignore this -DJ)
Step #2 of this ticket is to try moving the @Transactional annotation to the concrete classes to see if this A) still works and B) properly propagates the transaction/error/rollback