Warum schreibt CMT beim Beenden der EJB-Methode ein, wenn das Transaktionsattribut "Required" lautet?

ERFORDERLICH kann böse sein

Mir persönlich gefällt das Attribut REQUIRED nicht, und ich rate dringend davon ab, es zu benutzen.

Das mühsame Erstellen von Transaktionen (was REQUIRED tut) führt dazu, dass man nicht wirklich weiß, wann und wo eine Transaktion tatsächlich gestartet wurde und wann sie ausgeführt wird. Das ist nicht eine gute Sache. Leute sollten Transaktionsgrenzen explizit entwerfen.

MANDATORY und UserTransaction sind Seelenverwandte

Ihr Wunsch, UserTransaction zu verwenden, ist sehr gut und funktioniert mit CMT - es gibt keinen Unterschied zwischen einer JTA-Transaktion, die über UserTransaction vom Container gestartet wurde, oder einer JTA-Transaktion, die für Sie gestartet wurde durch den Container.

Der Ansatz, den ich empfehlen würde, besteht darin, die gesamte erforderliche Verwendung auf OBLIGATORISCH umzustellen. Mit MANDATORY wird der Container nicht Transaktionen für Sie starten. Stattdessen schützt es Ihre Bean, indem sichergestellt wird, dass sie nicht aufgerufen werden kann, solange keine Transaktion läuft. Dies ist eine erstaunliche und wenig genutzte Funktion. MANDATORY ist der beste Freund von allen, die eine wahrhaft deterministische Transaktions-App erstellen und durchsetzen wollen. Mit diesem Setup könnten Sie sich in CMT verlieben.

In diesem Szenario starten Sie die Transaktionen mit UserTransactions und dann ist der Container wie Ihr großer Bodyguard, der Leute an den Randstein tritt, es sei denn, sie haben eine Transaktion ordnungsgemäß gestartet, bevor Sie versuchen, Ihren Code aufzurufen.

Überlegungen

• Ein Servlet oder ein BMT EJB kann eine UserTransaction verwenden.
• CMT-Beans können keine UserTransaction verwenden, aber sie können an einer Transaktion teilnehmen, die von einer UserTransaction gestartet wurde (wie oben erwähnt, ist eine JTA-Transaktion eine JTA-Transaktion).
• BMT-Beans können nicht an einer bestehenden Transaktion teilnehmen. Wenn Sie eine BMT-Bean aufrufen, während eine Transaktion bereits ausgeführt wird, wird die Transaktion vor dem Aufrufen der BMT-Bean vom Container angehalten und nach Abschluss der Methode fortgesetzt.
• @Resource UserTransaction wird Ihnen die Benutzertransaktion per Injektion geben
• java:comp/UserTransaction wird Ihnen die Benutzertransaktion über die Suche
liefern
• @TransactionAttribute(MANDATORY) , das auf Klassenebene verwendet wird, wirkt sich auf die Methoden dieser exakten Klasse aus (d. h. die Methoden fooClass.getDecaredMethods() ). Methoden von Superklassen und Unterklassen werden standardmäßig auf @TransactionAttribute(REQUIRED) gesetzt, es sei denn, diese Klassen sind explizit mit Anmerkungen versehen.% Co_de%
• Wenn es Ihnen schlecht wird, @TransactionAttribute(MANDATORY) und userTransaction.begin() aufzurufen und die zugehörige Ausnahmebehandlung durchzuführen, betrachten Sie userTransaction.commit() . Ihre Transaktionsgrenzen sind weiterhin dokumentiert und explizit.
• @TransactionAttribute(REQUIRES_NEW) s, das von einer Methode einer CMT-Bean ausgelöst wird, bewirkt, dass die Transaktion für das Rollback markiert wird, selbst wenn Sie die Ausnahme im aufrufenden Code abfangen und behandeln. Verwenden Sie RuntimeException , um dies von Fall zu Fall für benutzerdefinierte Laufzeitausnahmeklassen zu deaktivieren.

Verlust des Transaktionskontextes

Einige Dinge können dazu führen, dass Ihre laufende Transaktion angehalten, ausgesetzt oder auf andere Weise nicht an die aufgerufene Bean weitergegeben wird.

• BMT-Beans stoppen die Transaktionsausbreitung. Wenn eine laufende Transaktion eine BMT-Bean aufruft, wird diese Transaktion vor dem Aufruf der BMT-Bean angehalten und nach der Rückkehr der Bean fortgesetzt. BMT-Beans können Ursprung von Transaktionen sein, können aber nicht an bestehenden Transaktionen teilnehmen. Wenn die Weitergabe auf mysteriöse Weise fehlschlägt, stellen Sie sicher, dass während der Transaktion keine unbeabsichtigten Aufrufe an BMT-Beans erfolgen.
• Verwenden Sie keine anderen als von einem Container bereitgestellten UserTransaction- oder Container-Methoden wie SessionContext.setRollbackOnly, um Transaktionen zu verwalten. Die Verwendung einer "Ressourcen-Manager-spezifischen Transaktions-Demarkations-API" wie JPA @ApplicationException oder EntityTransaction umgeht die Transaktionsverwaltung.
• Beginne nicht deine eigenen Threads. Die Transaktionsausbreitung erfolgt auf einer Pro-Thread-Basis. In Java EE gibt es no Standard-APIs, die eine Transaktion unterstützen, die mehrere Threads umfasst. Wenn Sie den Thread entweder davon abhalten, einen eigenen Thread zu starten oder @Asynchronous zu verwenden, hinterlassen Sie Ihre bestehende Transaktion.