Priorität der Festschreibung von transaktionsorientierten Ressourcen

Sie können die Reihenfolge angeben, in der die transaktionsorientierten Ressourcen während der zweiphasigen Festschreibung verarbeitet werden.

Wenn Sie die Reihenfolge festlegen, in der die transaktionsorientierten Ressourcen während der zweiphasigen Festschreibung verarbeitet werden, hat dies zwei wichtige Vorteile:
  • Die Optimierung einphasiger Festschreibung findet häufiger statt.
  • Potenzielle Probleme, die die Transaktionsisolation verursachen kann, werden behoben.

Damit Sie die Reihenfolge festlegen können, in der die transaktionsorientierten Ressourcen während der zweiphasigen Festschreibung verarbeitet werden, müssen Sie die Priorität der Festschreibung für eine Ressource angeben, indem Sie das Attribut für Festschreibungspriorität für eine Ressourcenreferenz festlegen. Je höher die Festschreibungspriorität einer Ressource ist, desto früher wird diese verarbeitet. Wenn einer Ressource beispielsweise eine Festschreibungspriorität von 10 zugeordnet ist, wird sie vor einer Ressource mit einer Festschreibungspriorität von 1 verarbeitet. Der Wert der Festschreibungspriorität kann eine ganze Zahl zwischen -2147483648 und 2147483647 ein.

Wenn Sie keinen Wert für die Priorität der Festschreibung angeben, wird der Ressource der Standardwert null zugeordnet. Dieser Wert wird verwendet, wenn die Reihenfolge der Ressourcen zur Ausführungszeit festgelegt wird. Werden zwei oder mehr Ressourcen mit derselben Priorität oder der Standardpriorität konfiguriert, wird bei der Verarbeitung dieser Ressourcen keine bestimmte Reihenfolge eingehalten.

Das Attribut für Festschreibungspriorität kann für eine Ressource mit den Rational-Application Developer-Tools festgelegt werden. Nähere Informationen hierzu finden Sie im Information Center zu Rational Application Developer. Die Anwendungskomponente muss einen Implementierungsdeskriptor verwenden. Dieses Attribut kann nicht angegeben werden, wenn eine Annotation verwendet wurde.

Optimierung der einphasigen Festschreibung

Wenn in einer Transaktion mit zweiphasiger Festschreibung alle Ressourcen mit Ausnahme der zuletzt in der Transaktion registrierten Ressource angeben, dass sie schreibgeschützt und daher nicht am Ergebnis der Transaktion interessiert sind, kann eine einphasige Festschreibung stattfinden. Dies bedeutet, dass der Transaktionsservice keine Ressourcen- und Transaktionsinformationen speichern muss, die für ein Rollback der zweiphasigen Festschreibung erforderlich wären, sodass die Leistung verbessert wird.

Sie können die Reihenfolge festlegen, in der die transaktionsorientierten Ressourcen während der zweiphasigen Festschreibung verarbeitet werden. Auf diese Weise können Sie die Ressourcen, die voraussichtlich angeben werden, dass sie schreibgeschützt sind, zuerst verarbeiten. Dadurch wird die Wahrscheinlichkeit, dass eine einphasige Festschreibung stattfinden wird, erhöht.

In der Regel ist Ihnen bekannt, welche Arbeit eine bestimmte transaktionsorientierte Ressource zur Ausführungszeit durchführen wird. Wenn Sie daher die Reihenfolge festlegen können, in der die Ressourcen in einer Transaktion verarbeitet werden, können Sie auch die Wahrscheinlichkeit erhöhen, dass eine Optimierung der einphasigen Festschreibung stattfinden wird.
[z/OS]config: Wenn Sie den MQ-Ressourcenadapter mit einer Aktivierungsspezifikation verwenden, kann der Anwendungsserver RRS-Transaktionen nicht dahingehend optimieren, dass sie eine einphasige Festschreibung verwenden. Verwenden Sie Listener-Ports, wenn Sie diese Funktion benötigen.

Transaktionsisolation

Wenn Ressourcen an einer globalen Transaktion mitwirken, sind Aktualisierungen, die als Teil einer Transaktion ausgeführt werden, außerhalb der Transaktion erst dann sichtbar, wenn die Transaktion festgeschrieben wird, d. h. diese Ressourcen sind isoliert. Diese Isolation kann Probleme mit anderen Anwendungskomponenten verursachen, die die Aktualisierungen bearbeiten, nachdem diese festgeschrieben wurden. Beispielsweise kann die weitere Verarbeitung scheitern oder zeitweilig fehlschlagen, weil Aktualisierungen abhängig von Reihenfolge und Zeit sind. Dieses Problem tritt bei der SIB-Messaging-Arbeit in WebSphere Application Server nicht auf (SIB = Service Integration Bus), kann jedoch für andere Messaging-Provider, z. B. für WebSphere MQ, ein Problem darstellen.

Wenn Sie die Reihenfolge festlegen, in der die transaktionsorientierten Ressourcen festgeschrieben werden, werden isolationsbedingte Probleme für alle transaktionsorientierten Systeme gelöst, nicht nur für Messaging-Provider und SIB.

Das folgende Beispiel beschreibt, wie Probleme auftreten können, wenn Sie die Reihenfolge, in der transaktionsorientierte Ressourcen festgeschrieben werden, nicht angeben können. Eine Anwendung aktualisiert eine Zeile in einer Datenbanktabelle und sendet anschließend eine JMS-Nachricht, die die weitere Verarbeitung der Zeile auslöst. Diese beiden Aktionen werden in derselben globalen Transaktion ausgeführt, daher werden sie so lange isoliert, bis ihre zugehörigen Ressourcen festgeschrieben werden. Wird die Aktualisierung der Zeile bereits vor dem Senden der Nachricht festgeschrieben, kann die durch die Nachricht ausgelöste Verarbeitung auf die aktualisierte Zeile zugreifen und diese verarbeiten. Wird die Aktion zum Senden der Nachricht zuerst festgeschrieben, kann diese Aktion die zusätzliche Verarbeitung der Zeile auslösen, bevor die Datenbank die Aktualisierung der Zeile festgeschrieben hat. In dieser Situation ist die aktualisierte Zeile weiterhin isoliert und nicht sichtbar, daher schlägt die weitere Verarbeitung der Zeile fehl.

Dieses Problem kann noch komplizierter sein, weil Aktualisierungen abhängig von Reihenfolge und Zeit sind. Wird die Datenbank zuerst festgeschrieben, tritt dieses Problem nicht auf. Wird die Aktion zum Senden der Nachricht zuerst festgeschrieben, kann das Problem auftreten, dies ist aber davon abhängig, ob die Arbeit der Datenbank festgeschrieben wurde, bevor die Nachricht die weitere Verarbeitung der Zeile auslöst. Daher kann das Problem nur zeitweilig auftreten und ist schwerer zu diagnostizieren.

Hinweise zu früheren Versionen von WebSphere Application Server

Wenn Sie die Festschreibungspriorität für eine Ressource festlegen, d. h., wenn Sie einen anderen Wert als den Standardwert 0 angeben, wird diese dem Partnerprotokoll in einem wiederherstellbaren Einheitenabschnitt hinzugefügt. Dieser Abschnitt in der Protokolldatei wird in WebSphere Application Server Version 7.0 oder höher erkannt, aber nicht in früheren Versionen des Anwendungsservers.

Wenn eine Anwendung das Attribut für Prioritätsfestschreibung verwendet, können Sie diese Anwendung deshalb nicht in einem heterogenen Cluster installieren, in dem mindestens ein Server eine Version von WebSphere Application Server vor Version 7.0 hat.

Wenn eine in einem Cluster installierte Anwendung das Attribut für Prioritätsfestschreibung verwendet, können Sie diesem Cluster auch keinen Server hinzufügen, falls der Server eine Version vor WebSphere Application Server Version 7.0 hat.

Allgemeine Informationen zu den verschiedenen Versionen des Produkts finden Sie im Artikel mit der Übersicht über "Migration, Koexistenz und Interoperabilität".


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=cjta_rescom
Dateiname:cjta_rescom.html