Najważniejsze definicje transakcji oparte na adnotacjach i xml

Question

Nie mogłem znaleźć na ten temat ostatecznej odpowiedzi w dokumentach i chociaż wydaje się, że istnieje logiczna odpowiedź, nie można być pewnym. Scenariusz jest taki - masz definicję transakcji opartą na xml, taką jak:

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

Która zaleca wszystkie metody obsługi. Ale wtedy masz @Transactional na konkretnej klasie/metodzie, gdzie chcesz zastąpić atrybut propagation.

Oczywistym jest, że na poziomie metody zastępuje ten sam na poziomie klasy, ale czy zastępuje on <tx:advice> (i faktycznie, <aop:pointcut>)?

Mam nadzieję, że dwa kolektory nie zostanie utworzony na tej samej klasy (i cokolwiek dzieje się pierwszy rozpocznie transakcję)

Answer 1

Podziękowania dla skaffmana za jego wysiłek. Wreszcie myślę, że mam problem:

1. Zarówno <aop:advisor> i @Transactional (wraz z <tx:annotation-driven>) Tworzenie TransactionInterceptor wokół klasie docelowej (ten, którego metody mają być uruchamiane w transakcji).
2. Porada o niższym atrybucie order zastępuje drugą. Jeśli nie określono atrybutu zamówienia, zamówienie jest niezdefiniowane. Ale moje testy wykazały, że jeden z definicją najpóźniej w applicationContext.xml ma pierwszeństwo, choć to może nie być tak zawsze:

Gdy dwa rad zdefiniowane w różnych aspektach, zarówno trzeba uruchomić w tym samym punkcie przyłączenia , chyba że postanowisz inaczej, kolejność wykonania jest niezdefiniowana.

Przynajmniej takie jest zachowanie na wiosnę 2.5.6.

Answer 2

Po trochę kopania, myślę, że odpowiedź leży w TxAdviceBeanDefinitionParser.doParse. Logika mówi:

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

Biorąc jedyną rzeczą, która czyta @Transactional jest AnnotationTransactionAttributeSource, że silnie sugeruje mi, że <tx:advice> skonsultuje @Transactional wtedy i tylko wtedy <tx:attributes> nie jest określona, ​​więc żaden nadrzędny jest możliwe.

Jest to sprzeczne ze zwykłą zasadą "zasady najmniejszego zaskoczenia", ponieważ podobnie jak ty oczekiwałbym, że adnotacja będzie miała pierwszeństwo w stosunku do klasy lub metody. Zgłosiłbym problem na ich JIRA, aby zmienić to zachowanie.

Powiedziawszy to wszystko, nadal uważam, że warto spróbować tego, aby zobaczyć, co robi, ponieważ może działać przez jakiś inny mechanizm.