Definiciones de transacciones basadas en anotaciones y basadas en xml precedencia

Question

No pude encontrar una respuesta definitiva a esto en los documentos, y aunque parece haber una respuesta lógica, no se puede estar seguro. El escenario es esto - usted tiene una definición de transacciones basado en XML, como:

<tx:advice id="txAdvice" transaction-manager="jpaTransactionManager"> 
    <tx:attributes> 
     <tx:method name="*" propagation="REQUIRED" /> 
    </tx:attributes> 
</tx:advice> 

que aconseja a todos los métodos de servicio. Pero luego tiene @Transactional en una clase/método concreto, donde desea anular el atributo propagation.

Está claro que @Transactional en el método de nivel anula la misma a la altura de la clase, pero lo hace anulan la <tx:advice> (y, de hecho, la <aop:pointcut>)?

espero dos interceptores no se crearán en la misma clase, (y lo que pasa a ser primera se iniciará la transacción)

Answer 1

Gracias a skaffman por su esfuerzo. Finalmente creo que tengo el comportamiento:

1. Tanto <aop:advisor> y @Transactional (junto con <tx:annotation-driven>) crear un TransactionInterceptor alrededor de la clase de destino (el uno, cuyos métodos se van a ejecutar en la transacción).
2. El consejo con un atributo order más bajo prevalece sobre el otro. Si no se especifica ningún atributo de orden, el orden no está definido. Pero mis pruebas mostraron que el definido más reciente en el applicationContext.xml tiene prioridad, aunque esto podría no ser el caso siempre:

Cuando dos consejos definen en diferentes aspectos tanto la necesidad de ejecutar al mismo unirse a punto , a menos que especifique lo contrario, el orden de ejecución no está definido.

Al menos este es el comportamiento de la primavera 2.5.6.

Answer 2

Después de un poco de excavación, creo que la respuesta está en TxAdviceBeanDefinitionParser.doParse. La lógica dice:

if <tx:attributes> is present then 
    parse <tx:attributes> 
else 
    instantiate an AnnotationTransactionAttributeSource to determine TX attributes 

Dado el único que lee @Transactional es AnnotationTransactionAttributeSource, que sugiere fuertemente a mí que <tx:advice> consultará @Transactional si y sólo si no se especifica <tx:attributes>, por lo que no es posible primordial.

Esto parece contradecir el enfoque habitual de Spring de "principio de sorpresa menor", ya que, como usted, esperaba que la anotación tuviera prioridad por clase o por método. Me gustaría presentar un problema en su JIRA para cambiar este comportamiento.

Habiendo dicho todo eso, sigo pensando que vale la pena intentarlo para ver qué hace, ya que puede funcionar por algún otro mecanismo.