@Transactional arbeitet nicht auf JNDI -DataSources ⇐ Java

[Anonymous]

Wir haben ein WebApp auf Wildfly ausgeführt, wobei JNDI -DataSources verwendet wird, um Datenbank -bezogene Operationen zu verarbeiten. Während eines Modernisierungsvorgangs wechseln wir derzeit EJBs in den Frühling als erster Schritt, um die Anwendung in der Lage zu machen, auf einem einfacheren Servlet -Container wie Tomcat auszuführen. /code> zu @Service und offensichtlich ändern @transactional Annotationen aus dem Jakarta Namespace in die Frühlingsanmerkungen> unser Transaktionsverhalten wird plötzlich unterbrochen. < Br /> Als Teil eines Testsuite haben wir einen TestCase, der ungefähr das folgende < /p>
macht

Code: Select all

// Within a @Transactional(REQUIRED) block
Connection con = getConnection(...) (1)
// do some sql updates (2)

try {
// Start @Transactional(REQUIRES_NEW) block
Connection con2 = getConnection(...) (3)
// do some more sql updates (4)
throw new Exception();
// End REQUIRES_NEW block
} catch (Exception ignored) {
}

// End Required block
< /code>
Die Erwartung wäre, dass unser Testfall mit den SQL -Updates aus (2) in der Datenbank sichtbar ist, die SQL Sollte innerhalb einer anderen Transaktion ausgeführt werden, die auf die Ausnahme zurückgeführt werden sollte. Es treten keine Rollbacks auf. Aus dem Aussehen sind Con und Con2 das gleiche Objekt oder zumindest auf dieselbe zugrunde liegende Wildfly -Transaktion. Und nur als Referenz: Wenn alle Bean- und TransaktionAntationen auf Jakarta -Anmerkungen umgestellt werden, funktioniert es auch. Der Block ist ein Rückruf, der in einer separaten Frühlingsbohne ausgeführt wird, die mit @Transactional 

kommentiert wird. Wir sehen Unsere Annahme ist, dass (3) die neu gestartete Transaktion nicht bewusst ist und uns das äußere Transaktionsobjekt gibt. Also schauten wir uns den Code an, der die Transaktion erhielt. Anfangs war dies eine Suche nach der Javax.initialContext . Wir gingen davon aus, dass eine Suche im Frühling den Trick ausführen könnte, und wechselte aus dem Frühling auf die JndidataSourcelookup , und als dies nicht der Trick getan hat, haben wir auch die resultierende DataSource über die DataSourceutils eingelegt Klasse aus dem Frühling. < /p>
Was haben wir falsch gemacht? Wie können wir eine zweite Verbindung erhalten, die an den inneren Transaktionskontext gebunden ist? Grund. Es scheint, dass der Frühling sich weigert, eine Transaktion zu öffnen, sobald eine offene Verbindung besteht.