Ich bin ein relativer Neuling für EJB. Hintergrund: Ich habe eine MDB, die den WebSphere-Standardnachrichtenanbieter verwendet, der MapMessages mit einer java.sql.DataSource empfängt, um etwas Arbeit zu verrichten, mit preparedstatement, jdbc transaction usw. Ich richte die MDB in der Datei ibm-ejb-bnd.xml ein ejb-jar.xml verwendet einen JCA-Adapter mit einer Aktivierungsspezifikation und einem Zielnamen. Ich habe eine java.sql.DataSource im ejb-jar und ibm-ejb-jar-bind hinzugefügt. Ich fügte auch die DataSource im MessageListener mit einer Annotation @Resource hinzu.
2 Szenarien habe ich Probleme zu verstehen (erstes Szenario behoben, siehe Update) ...
Container verwaltete MDB: Der DataSource-Treiber ist nicht XA-kompatibel. Daher habe ich in WebSphere "Last Participant Support" aktiviert. Immer noch, wenn der MDB-Transaktionstyp auf Container festgelegt ist, erhalte ich beim Commit einen Fehler:
%Vor%Vielleicht liegt das daran, dass nach dem Commit der DataSource zu MessageListener zurückgekehrt ist, der festlegt, dass es der letzte Teilnehmer ist? Ich glaube, dass der Standard-Messaging-Anbieter in WAS 7 XA-kompatibel ist, obwohl ich keine Dokumentation gesehen habe, die das explizit sagt.
Die Nachricht wird unmittelbar nach dem ersten Fehler noch vier Mal wiederholt (obwohl es eine Verzögerung von 30 Sekunden gemäß der ActivationSpec in WebSphere geben sollte). Jedes Mal wird der gleiche Fehler ausgelöst. Gemäß dem MessageListener ist es ohne Fehler beendet worden, also ist dieser Fehler ein Teil der wundervollen unsichtbaren behältergesteuerten Transaktion. Ich glaube nicht, dass ich globale XA-Transaktionen benötige, da es außer JMS nur eine einzige DataSource gibt. Ich habe das Rollback von Transaktionen programmgesteuert gehandhabt. Auch die JMS-Nachricht, MDB ist asynchron, AUTO-ACKNOWLEDGE. Sobald die Nachricht empfangen wurde, kann sie bestätigt werden.
Wenn ich einen Anwendungsfehler einfüge, so dass es eine Ausnahme gibt, sehe ich diesen Fehler sofort 5 Mal (keine Verzögerung):
%Vor%Also wechselte ich zu ................
Bean verwaltete MDB: Commit funktioniert ohne den XA-Fehler und passiert nur einmal. Die Fehlerbehandlung verhält sich jedoch immer noch nicht wie erwartet oder gewünscht! In der MessageListener-Klasse werfen abgefangene Exceptions eine EJB-Exception, was meiner Meinung nach dazu führen sollte, dass die MDB mein gewünschtes Verhalten hat: Die Ursache der Exception ist für mich nicht von Bedeutung, wenn eine MDB eine gefangene Exception auslöst Die MDB wird gemäß den Eigenschaften in WebSphereActivationSpec erneut versucht? Stattdessen wird die Nachricht fünfmal an den MessageListener gesendet, wobei derselbe Fehler wie bei Container Managed MDB ausgegeben wird: "EJB hat eine unerwartete (nicht deklarierte) Ausnahme ausgelöst ..."
Wenn ich eine RuntimeException ausl \ u00f6ste, tritt die Meldung "unexpected (non-deklarated) expection" nicht auf, aber die Nachricht wird immer noch viermal wiederholt, anstatt auf die Wiederholungsverzögerung zu warten.
Vielen Dank für das Lesen, jede Hilfe oder Einsicht wird sehr geschätzt!
UPDATE: Ich habe die Probleme mit der XA-Kompatibilität gelöst, indem ich die Datenquelle auf XA-kompatibel umgestellt habe. In der WAS-Verwaltungskonsole: Ressourcen - & gt; JDBC-Provider - & gt; DB2 Universal JDBC-Treiberanbieter - & gt; Ändern Sie den Namen der Implementierungsklasse in: com.ibm.db2.jcc.DB2XADataSource
Ich habe immer noch das gleiche Problem, wenn die Nachricht fehlschlägt. Es wird sofort und nicht gemäß der ActivationSpec in WAS wiederholt.
Ich glaube, das Wiederholungsintervall in der Aktivierungsspezifikation bezieht sich auf geschlossene Verbindungen, nicht auf fehlgeschlagene Nachrichten.
Sie sollten das gewünschte Intervall im SIB-Ziel definieren
Busse & gt; BUS & gt; Ziele & gt; REISEZIEL
Sehen Sie sich das Ausnahmeziel an
Maximale Anzahl fehlgeschlagener Zustellungen pro Nachricht ist, wie oft die Nachricht gesendet wird, bis sie als fehlgeschlagen deklariert wird (Standard ist 5, weshalb Sie vier weitere Male erhalten)
Wenn die Nachrichten fehlschlagen, werden sie entweder in eine Ausnahmezielwarteschlange verschoben oder nach einer bestimmten Zeit, die auf Busebene festgelegt ist, aber für jedes Ziel überschrieben werden kann, erneut auf None gesetzt (siehe Messaging-Engine überschreiben geblockt Wiederholungs-Timeout-Standard)
Ich weiß nicht, ob Sie es noch brauchen, aber Sie sollten die benutzerdefinierte Eigenschaft überprüfen:
sib.processor.blockedRetryTimeout für eine Messaging-Steuerkomponente definiert.
Es ist das, wonach Sie suchen. Während der Zeit, in der die Nachricht auf ihre erneute Zustellung wartet, befindet sie sich im Status UNLOCKED und kann folglich verworfen werden.
Tags und Links java jms websphere ejb message-driven-bean