Jemand setzt Transactional auf eine Methode und es scheint nicht zu wirken. Was sind die üblichen Gründe?

Die Annotation wird über einen Proxy umgesetzt, sie greift also nur, wenn der Aufruf von außen durch die Bean geht. Ein Aufruf aus einer anderen Methode derselben Klasse umgeht den Proxy komplett, und das ist die häufigste Ursache. Andere Gründe: die Methode ist nicht public, die geworfene Exception ist checked und löst per Default kein Rollback aus, die Bean wurde außerhalb des Containers erzeugt, oder es war eine neue Transaktion nötig und die Propagation blieb auf required.

In neun von zehn Fällen ist es der Selbstaufruf. Spring wickelt die Bean in einen Proxy, und die Transaktion startet, wenn ein Aufrufer durch diesen Proxy geht. Ruft also eine public Methode derselben Klasse die annotierte Methode direkt auf, verlässt der Aufruf das Objekt nie und es beginnt keine Transaktion. Der Fix ist, die Methode in eine andere Bean zu verschieben oder die Bean in sich selbst zu injizieren, und der ehrliche Fix ist meist, dass die Grenze sowieso an der falschen Stelle saß. Danach prüfe ich die Basics: die Methode sollte public sein, die Bean muss Spring-verwaltet sein und nicht mit new erzeugt, und die Rollback-Regel erwischt viele, weil per Default nur bei Unchecked Exceptions zurückgerollt wird, eine Checked Exception committet also, solange ich kein rollbackFor angebe. Ich schaue außerdem auf die Propagation, denn Arbeit, die das Rollback des Aufrufers überleben muss, braucht requires new, und das kostet eine zweite Verbindung, was bei kleinem Pool zählt. Und ich halte Transaktionen kurz: keine HTTP-Calls, kein Publishing von Nachrichten, kein Warten auf irgendetwas darin, denn eine Datenbankverbindung zu halten, während man einen Drittanbieter anruft, ist der schnellste Weg, einen Pool leerzuräumen.