Nachrichtenzuverlässigkeitsstufen - JMS-Zustellmodus und Servicequalität der Serviceintegration

Nachrichten haben ein Servicequalitätsattribut, das Sie verwenden können, um anzugeben, wie zuverlässig die Nachrichtenzustellung sein wird. JMS-Anwendungen senden Nachrichten mit einem JMS-Zustellmodus (persistent oder nicht persistent). Anschließend verwendet die Serviceintegration JMS-Verbindungsfactory-Einstellungen, um den JMS-Zustellmodus einer Nachrichtenzuverlässigkeitseinstellung der Serviceintegration zuzuordnen. Zusätzliche Einstellungen in Busziele (einschließlich fremder ziele und Aliasziele) können diese Nachrichtenzuverlässigkeit überschreiben.

Anmerkung: Der Begriff "Nachrichtenzuverlässigkeitsstufe" entspricht allen folgenden Begriffen:
  • Servicequalität (QoS, Quality of Service) - Messaging der Serviceintegration
  • Zustellmodus - JMS
  • Persistenz - IBM MQ
Sie können die folgenden Nachrichtenzuverlässigkeitsstufen der Serviceintegration für Nachrichten angeben. Die Optionen sind aufsteigend nach Zuverlässigkeit sortiert.
Bestmöglich, nicht persistent
Nachrichten werden verworfen, wenn eine Messaging-Engine gestoppt wird oder ein Fehler auftritt. Nachrichten können auch verworfen werden, wenn die Verbindung, in der sie übertragen wurden, nicht mehr verfügbar ist oder wenn die Systemressourcen knapp werden.
Express, nicht persistent
Nachrichten werden verworfen, wenn eine Messaging-Engine gestoppt wird oder ein Fehler auftritt. Nachrichten können auch verworfen werden, wenn die Verbindung, in der sie übertragen wurden, nicht mehr verfügbar ist.
Zuverlässig, nicht persistent
Nachrichten werden verworfen, wenn eine Messaging-Engine gestoppt wird oder ein Fehler auftritt.
Zuverlässig, persistent
Nachrichten können verworfen werden, wenn eine Messaging-Engine ausfällt.
Garantiert, persistent
Nachrichten werden nicht verworfen.
Anmerkung: Eine höhere Zuverlässigkeitsstufe hat einen höheren Einfluss auf die Leistung.

JMS-Anwendungen senden Nachrichten mit einem JMS-Zustellmodus (persistent oder nicht persistent). Anwendungen können diesen Zustellmodus als Parameter der JMS-Methode send() angeben, aber Sie können optional einen Zustellmodus, der die Methode send() überschreibt, als Attribut des JMS-Ziels angeben.

Die Serviceintegration verwendet die Einstellungen der JMS-Verbindungsfactory, um die JMS-Zustellungsmodi (persistent und nicht persistent) Nachrichtenzuverlässigkeitsstufen der Serviceintegration zuzuordnen. Diese Zuordnung ermöglicht Ihnen die Wahl zwischen hoher Leistung, hoher Zuverlässigkeit oder etwas dazwischen. Sie können die erforderliche Zuordnung in den Einstellungen der JMS-Verbindungsfactory festlegen. Sehen Sie sich beispielsweise Einheitliche Verbindungsfactory für den Standard-Messaging-Provider [Einstellungen] an.

Wichtig: Wenn Sie den persistenten JMS-Zustellmodus einer der nicht persistenten Stufen der Serviceintegration zuordnen (Bestmöglich, nicht persistent, Express, nicht persistent oder Zuverlässig, nicht persistent), riskieren Sie einen Nachrichtenverlust unter bestimmten Umständen. Sie laufen beispielsweise Gefahr, Nachrichten beim Serverneustart oder bei hoher Arbeitslast zu verlieren.

Sie geben die Standardzuverlässigkeitsstufe und die maximale Zuverlässigkeitsstufe der Serviceintegration als Attribut von Buszielen (einschließlich fremder Ziele und Aliasziele) an. Außerdem können Sie angeben ob die vom Erzeuger angegebene Zuverlässigkeit die Standardzuverlässigkeit für das Ziel überschreibt. Wenn nicht, setzt die Serviceintegration die Zuverlässigkeitsstufe der Nachrichten auf die Standardzuverlässigkeit für das Ziel zurück. Für Aliasziele können Sie angeben, dass die Zuverlässigkeitseinstellung vom geplanten Ziel übernommen werden soll.

Für die Interoperation mit IBM MQ ordnen Sie die Zuverlässigkeitseinstellungen für Serviceintegrationsnachrichten den Persistenzeinstellungen für IBM MQ-Nachrichten zu. Weitere Informationen finden Sie im Artikel Zuordnung der JMS-Zustelloption sowie der Nachrichtenzuverlässigkeit und IBM MQ-Persistenzwerten.

Zu Ihrer Unterstützung bei der Auswahl der erforderlichen Zuverlässigkeitsstufe veranschaulicht die folgende Tabelle das Verhalten der fünf Zuverlässigkeitsstufen.
Anmerkung: Zusätzlich zur Festlegung der ausgewählten Zuverlässigkeitsstufe muss Ihre Anwendung transaktionsorientiert sein, damit Nachrichten beim Auftreten verschiedender in der Tabelle gezeigten Fehler bei bestimmten Zuverlässigkeitsstufen nicht verloren gehen.
Tabelle 1. Verhalten der fünf Zuverlässigkeitsstufen. In den fünf Spalten der Tabelle sind die fünf Nachrichtenzuverlässigkeitsstufen und das entsprechende Verhalten aufgelistet.
  Bestmöglich, nicht persistent Express, nicht persistent Zuverlässig, nicht persistent Zuverlässig, persistent Garantiert, persistent
JMS-Zustellmodus: Nicht persistent Nicht persistent Nicht persistent Persistent Persistent
Transaktionsorientiert, atomar: Nein, einzelne Nachrichten können gelöscht werden. Ja, Nachrichten werden nicht gelöscht und bleiben bei einem Serverneustart nie erhalten. Ja, Nachrichten werden nicht gelöscht und bleiben bei einem Serverneustart nie erhalten. Ja Ja
Nachrichten werden festgehalten: Nein Möglich: Wenn sich Nachrichten an einem Ziel anhäufen. Möglich: Wenn sich Nachrichten an einem Ziel anhäufen. Ja: Asynchron Ja: Synchron
Nachrichten werden im normalen Betrieb verworfen: Ja Nein Nein Nein Nein
Nachrichten werden dupliziert. Nein Möglich, Statusdaten können bei einem Serverabsturz verloren gehen, was zu einer Duplizierung führt. Möglich, Statusdaten können bei einem Serverabsturz verloren gehen, was zu einer Duplizierung führt. Möglich: Da das Löschen aus der Datenbank bezogen auf Benutzeranforderungen asynchron erfolgt. Nein
Nachrichten gehen bei einer geplanten Beendigung nicht verloren: Nein Nein Nein Ja: Auf Platte gespeicherte Nachrichten werden wiederhergestellt. Bei einem geplanten Systemabschluss werden Nachrichten aus dem Cache auf Platte gespeichert. Ja
Nachrichten gehen bei Clientkommunikationsfehlern nicht verloren: Nein Nein Ja Ja Ja
Nachrichten gehen bei Kommunikationsfehlern der Engine nicht verloren: Nein Ja Ja Ja Ja
Nachrichten gehen beim Absturz der Engine nicht verloren: Nein Nein Nein Möglich: Auf Platte gespeicherte Nachrichten werden wiederhergestellt. Ja
Nachrichten gehen bei einer geplanten Beendigung nicht verloren: Nein Nein Nein Möglich: Auf Platte gespeicherte Nachrichten können gesichert und wiederhergestellt werden. Ja
Im Folgenden finden Sie Erläuterungen zu den Zeilenüberschriften in der Tabelle:
JMS-Zustellmodus
Für JMS-Objekte wie Verbindungsfactorys und Ziele ist dies die Zuordnung zwischen dem JMS-Zustellmodus und den Zuverlässigkeitseinstellungen. Die Standardzuordnung für den JMS-Zustellmodus Nicht persistent ist Express, nicht persistent. Die Standardzuordnung für den JMS-Zustellmodus Persistent ist Zuverlässig, Persistent.
Transaktionsorientiert, atomar
Gibt an, ob die Nachricht im Verhältnis zu anderen Nachrichten, die in derselben Transaktion erzeugt oder konsumiert werden, atomar ist. Nachrichten des Typs Bestmöglich sind zu dem Zeitpunkt, zu dem sie erzeugt werden, im Verhältnis zu anderen Nachrichten transaktionsbezogen nicht atomar. Wenn eine solche Nachricht verloren geht (siehe die Beschreibung für die Einstellung "Bestmöglich, nicht persistent" weiter oben in diesem Artikel), können andere Nachrichten in derselben Transaktion trotzdem ordnungsgemäß zugestellt werden, wenn die Transaktion festgeschrieben wird (wenn die Transaktion rückgängig gemacht wird, werden alle Nachrichtenoperationen, unabhängig von ihrer Zuverlässigkeit, ebenfalls rückgängig gemacht). Wenn ein Fehler auftritt, der zum Verlust einer der Nachrichten in der Transaktion führt, wird bei Nachrichten mit einer höheren Verfügbarkeit die Transaktion und die gesamte, in dieser Transaktion ausgeführte Arbeit rückgängig gemacht. Damit wird die Operation transaktionsbezogen atomar.
Nachrichten werden festgehalten
Gibt an, ob Nachrichten in den Datenspeicher oder den Dateispeicher auf der Platte geschrieben werden. Die Häufigkeit, mit der Nachrichten auf Platte geschrieben werden, wirkt sich auf die Systemleistung aus. Im Allgemeinen kann mit einem Dateispeicher für die Messaging-Engine eine bessere Leistung erzielt werden. Nachrichten mit der Zuverlässigkeit Bestmöglich, nicht persistent werden nie auf die Platte geschrieben. Nachrichten mit der Zuverlässigkeit Express, nicht persistent und Zuverlässig, nicht persistent werden auf die Platte geschrieben, wenn sich Nachrichten an einem Ziel anhäufen. Nachrichten mit der Zuverlässigkeit Zuverlässig, persistent und Garantiert, persistent werden immer auf die Platte geschrieben.

Nachrichten mit der Zuverlässigkeit Zuverlässig, persistent werden ebenfalls auf Platte geschrieben, allerdings erfolgt dies bezogen auf die erzeugende Anwendung asynchron. Auf diese Weise können Datenbankupdates flexibel geplant und im Stapelbetrieb ausgeführt werden, um den Durchsatz zu erhöhen. Unter normalen Bedingungen gehen Nachrichten nicht verloren. Sie gehen jedoch verloren, wenn eine Messaging-Engine ausfällt, bevor dieser asynchrone Schreibvorgang abgeschlossen ist.

Nachrichten mit der Zuverlässigkeit Garantiert, persistent werden bezogen auf die erzeugende Anwendung synchron auf Platte geschrieben.

Wenn es zulässig ist, dass sich Nachrichten an einem Ziel anhäufen, weil sie nicht schnell genug konsumiert werden können, wie sie erzeugt werden, kann eine Messaging-Engine Nachrichten auf die Platte schreiben, um die Speicherbelegung zu verwalten.

Wenn eine Nachricht mit einer höheren Servicequalität als Bestmöglich, nicht persistent auf die Platte geschrieben wird, kann sie auch in einem Hauptspeicherpuffer zwischengespeichert werden.

Nachrichten werden im normalen Betrieb verworfen
Gibt an, ob Nachrichten im normalen Betrieb gelöscht werden.
Anmerkung:
Wenn Sie eine nicht transaktionsorientierte Message-driven Bean (MDB) haben, löscht das System die Nachricht beim Bean-Start oder bei Beendigung der Bean. Wenn die Bean eine Ausnahme generiert und deshalb nicht beendet wird, führt das System eine der folgenden Aktionen aus:
  • Wenn das System so konfiguriert ist, dass die Nachricht bei Beendigung der Bean gelöscht wird, wird die Nachricht einer neuen Instanz der Bean zugestellt, sodass es eine neue Gelegenheit zur Verarbeitung der Nachricht gibt.
  • Wenn das System so konfiguriert ist, dass die Nachricht beim Bean-Start gelöscht wird, geht die Nachricht verloren.

Die Nachricht wird beim Bean-Start gelöscht, wenn die Servicequalität auf Bestmöglich, nicht persistent gesetzt ist. Bei allen anderen Servicequalitäten wird die Nachricht bei Beendigung der Bean gelöscht.

Nachrichten werden dupliziert
Gibt an, ob Nachrichten nach einem Serverfehler dupliziert werden.
Nachrichten gehen bei einer geplanten Beendigung nicht verloren:
Gibt an, ob Nachrichten bei einem geplanten Systemabschluss oder Systemstart erhalten bleiben.
Nachrichten gehen bei Clientkommunikationsfehlern nicht verloren:
Gibt an, ob Nachrichten bei einem Ausfall der Kommunikation zwischen Client und Messaging-Engine erhalten bleiben.
Nachrichten gehen bei Kommunikationsfehlern der Engine nicht verloren:
Gibt an, ob Nachrichten bei einem Ausfall der Kommunikation zwischen Messaging-Engines erhalten bleiben.
Nachrichten gehen beim Absturz der Engine nicht verloren:
Gibt an, ob Nachrichten beim Absturz einer Messaging-Engine oder eines Servers erhalten bleiben.
Nachrichten gehen bei einer geplanten Beendigung nicht verloren:
Gibt an, ob Nachrichten eine Onlinesicherung und -wiederherstellung überstehen.

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjj9000_
Dateiname:cjj9000_.html