I couldn’t find a definitive answer to this in the docs, and although there seems to be a logical answer, one can’t be sure. The scenario is this – you have a xml-based transaction definition, like:
<tx:advice id="txAdvice" transaction-manager="jpaTransactionManager"> <tx:attributes> <tx:method name="*" propagation="REQUIRED" /> </tx:attributes> </tx:advice>
Which advises all service methods. But then you have
@Transactional on a concrete class/method, where you want to override the propagation attribute.
It is clear that
@Transactional at method-level overrides the same one at class-level, but does it override the
<tx:advice> (and actually, the
It turns out the behaviour is less than expected:
<tx:annotation-driven>) create a
TransactionInterceptoraround the target class (the one, whose methods are to be run in transaction).
- The advice with a lower
orderattribute overrides the other one. If no order attribute is specified, the order is undefined. But my tests showed that the one defined latest in the
applicationContext.xmltakes precedence, although this might not be the case always:
When two pieces of advice defined in different aspects both need to run at the same join point, unless you specify otherwise the order of execution is undefined.
This is the behaviour for spring 2.5.6. Spring 3.0 might have redefined this.