Wie fangen und umbrechen Sie Exceptions, die von JTA ausgelöst werden, wenn ein Container-Managed-TX EJB festlegt?

Gibt es eine Einschränkung zu dem, was ich sagte über REQUIRES_NEW und der BMT in der ursprünglichen Frage.

Finden Sie in der EJB-3.1-Spezifikation, Abschnitt 13.6.1 Bean-Managed Transaction Demarcationin Container Verantwortlichkeiten. Es liest:

Den container verwalten müssen, die client-Aufrufe an eine enterprise-bean
Instanz mit bean-managed transaction demarcation wie folgt. Wenn ein
client ruft business Methode über eine enterprise-bean ist
client-Ansichten, die container unterbricht jede Transaktion werden
im Zusammenhang mit der client-Anfrage. Wenn es eine Verhandlung gibt
im Zusammenhang mit der Instanz (dies würde geschehen, wenn eine stateful session
bean-Instanz gestartet, die Transaktion in einigen vorherigen Geschäft
Methode), der container ordnet die Ausführung der Methode mit dieser
Transaktion. Wenn es interceptor-Methoden im Zusammenhang mit der Bohne
Instanzen, die diese Maßnahmen ergriffen werden, bevor die interceptor-Methoden sind
aufgerufen.

(Kursiv von mir). Das ist wichtig, weil es bedeutet, dass ein BMT EJB Erben nicht die JTA-tx von einem Anrufer, die über eine zugehörige container managed tx. Alle aktuellen tx ist ausgesetztso dass, wenn ein BMT EJB erstellt einen tx es ist eine neue Transaktion, und wenn Sie verpflichtet, Sie verpflichtet nur seine Transaktion.

Das bedeutet, dass Sie verwenden können, eine BMT-EJB-Methode, beginnt und verpflichtet, eine Transaktion, als wenn es effektiv REQUIRES_NEW und tun Sie etwas wie dieses:

@Stateless
@TransactionManagement(TransactionManagementType.BEAN)
class TheEJB {

    @Inject private EntityManager em;

    @Resource private UserTransaction tx; 

    //Note: Any current container managed tx gets suspended at the entry
    //point to this method; it's effectively `REQUIRES_NEW`.
    //
    public methodOfInterest() throws AppValidationException, SomeOtherAppException {
       try {
           tx.begin();
           //For demonstration's sake create a situation that'll cause validation to
           //fail at commit-time here, like
           someEntity.getCollectionWithMinSize1().removeAll();
           em.merge(someEntity);
           tx.commit();
       } catch (ValidationException ex) {
           throw new AppValidationException(ex);
       } catch (PersistenceException ex) {
           //Go grubbing in the exception for useful nested exceptions
           if (isConstraintViolation(ex)) {
               throw new AppValidationException(ex);
           } else {
               throw new SomeOtherAppException(ex);
           }
       }
    }

}

Dadurch wird die commit-unter meiner Kontrolle. Wo brauche ich nicht eine Transaktion über mehrere Aufrufe über mehrere verschiedene EJBs dies ermöglicht es mir, um alle Fehler, einschließlich Fehler bei commit, in meinem code.

Den Java EE 6 tutorial-Seite, auf der bean-verwalteten Transaktionen nicht erwähnen, oder irgendetwas anderes über, wie BMTs genannt werden.

Reden das BMT nicht in der Lage, zu simulieren REQUIRES_NEW in den blogs, die ich verlinkt gültig ist, nur unklar. Wenn Sie eine bean-managed Transaktions-EJB Sie nicht anhalten einer Transaktion dass Sie begonnenum zu beginnen ein weiterer. Ein Aufruf einer separaten Helfer EJB aussetzen, Ihre tx und geben Sie den Gegenwert von REQUIRES_NEW ich aber noch nicht getestet.

Die andere Hälfte der problem - Fälle, in denen ich, vom container verwaltete Transaktionen, da habe ich eine Arbeit, die getan werden muss, über verschiedene EJBs und EJB-Methoden - ist gelöst mit einer defensiven Codierung.

Frühen eifrig Spülung der entity-manager ermöglicht es mir, zu fangen alle Fehler bei der Validierung, dass meine JSR330 Validierungsregeln finden, so brauche ich nur, um sicherzustellen, dass Sie vollständig und umfassend, so dass ich nie eine check-Einschränkung oder Verletzung der Integrität Fehler aus der DB auf den commit-Zeitpunkt. Ich kann nicht behandeln Sie Sie sauber, so muss ich wirklich in der defensive zu vermeiden.

Teil der defensiven Codierung:

• Die starke Nutzung von javax.validation Anmerkungen auf entity-Felder, und die Verwendung von @AssertTrue Validierung von Methoden, bei denen das nicht genug ist.
• Validation-constraints, die auf Sammlungen, die ich war erfreut zu sehen, unterstützt werden. Ich habe zum Beispiel ein Unternehmen A mit einer Sammlung von B. A muss mindestens eine Balso habe ich ein @Size(min=1) Einschränkung der Sammlung von B wo es definiert ist in A.
• Benutzerdefinierte JSR330 Prüfungen. Ich habe mehrere benutzerdefinierte Validatoren für Dinge wie Australische Business-Nummern (ABNs) um sicherzustellen, dass ich nie versuchen, das senden einer ungültigen, um die Datenbank und die trigger eine DB-level validation error.
• Frühen Spülung der entity-manager mit EntityManager.flush(). Diese Kräfte Validierung stattfinden, wenn es unter der Kontrolle des Codes, nicht später, wenn JTA geht commit für die Transaktion aus.
• Entität-spezifische defensiv-code und die Logik in meinem EJB-Fassade, um sicherzustellen, dass Situationen, die nicht erkannt werden können, indem JSR330 überprüfung nicht auftreten, und führen commit fehlschlagen.
• Wo sinnvoll, mit REQUIRES_NEW Methoden zu zwingen, früh zu Begehen und lassen Sie mich behandeln Fehler in meinem EJBs, wiederholen Sie entsprechend, etc. Dies erfordert manchmal einen Helfer der EJB zu bekommen, um Probleme mit self-verbindungen auf business-Methoden.

Ich kann immer noch nicht ordnungsgemäß zu behandeln, und wiederholen Sie die Serialisierung Ausfälle oder Blockaden wie könnte ich, wenn ich mit JDBC direkt mit Swing -, also alle diese "Hilfe" aus dem container hat mich ein paar Schritte rückwärts in einigen Bereichen. Es spart eine riesige Menge fummelig code und Logik in anderen Orten, aber.

Wo diese Fehler auftreten, ich habe ein UI-framework-level-exception filters. Er sieht die EJBException einwickeln der JTA RollbackException einwickeln der PersistenceException einwickeln der EclipseLink-spezifische Ausnahme einwickeln der PSQLException prüft die SQLState und macht Entscheidungen auf der Grundlage, dass. Es ist absurd Kreisverkehr, aber es funktioniert

InformationsquelleAutor der Antwort Craig Ringer

javax.die Validierung.ValidationException ist ein JDK Ausnahme; ich kann nicht
ändern Sie Sie, und fügen Sie eine @ApplicationException-annotation zu verhindern
Verpackung

In Ergänzung zu Ihrer Antwort: Sie können die XML-Deskriptor zu kommentieren 3rd-party-Klassen als ApplicationException.

InformationsquelleAutor der Antwort jjmontes