Verbindungskennungen

Eine Verbindungskennung ist eine Darstellung einer physischen Verbindung. Um eine Back-End-Ressource, z. B. eine relationale Datenbank, in WebSphere Application Server zu verwenden, müssen Sie eine Verbindung zu dieser Ressource aufbauen. Wenn Sie die Methode "getConnection()" aufrufen, wird eine "Verbindungskennung" zurückgegeben. Die Kennung ist nicht die physische Verbindung. Die physische Verbindung wird vom Verbindungsmanager verwaltet.

Es gibt zwei wesentliche Konfigurationen, die den Einsatz und das Verhalten von Verbindungskennungen beeinflussen. Dies ist zum ersten "res-sharing-scope". Diese Eigenschaft wird durch die Ressourcenreferenz definiert, die zum Suchen der Datenquelle oder Verbindungsfactory verwendet wird. Es teilt dem Verbindungsmanager mit, ob Sie diese Verbindung nutzen können.

Der zweite Faktor, der sich auf das Verhalten von Verbindungskennungen auswirkt, ist das Verwendungsmuster. Es gibt im Wesentlichen zwei Verwendungsmuster. Das erste ist das Muster "Abrufen/Verwenden/Schließen" (get/use/close). Bei diesem Verwendungsmuster führt eine Anwendung in einer einzigen Methode die folgenden Schritte aus und ruft dabei keine weitere Methode auf, die eine Verbindung von derselben Datenquelle oder Verbindungsfactory anfordern könnte. Eine Anwendung, die dieses Muster verwendet, geht wie folgt vor:
  1. Verbindung aufbauen
  2. die eigentliche Aufgabe ausführen
  3. festschreiben (sofern erforderlich)
  4. Verbindung schließen
Das zweite Verwendungsmuster ist das Muster "Zwischengespeicherte Kennung". Dabei führt eine Anwendung folgende Schritte aus:
  1. Verbindung aufbauen
  2. globale Transaktion beginnen
  3. in der Verbindung arbeiten
  4. globale Transaktion festschreiben
  5. in der Verbindung weiterarbeiten
Eine zwischengespeicherte Kennung ist eine Verbindungskennung, die von einer Anwendung über Transaktions- und Methodengrenzen hinweg gehalten wird. Beachten Sie die folgenden Hinweise für die Verwendung zwischengespeicherter Kennungen:
  • Für die Unterstützung zwischengespeicherter Verbindungskennungen ist es erforderlich, dass über diese Grenzen hinaus eine zusätzliche Verwaltung der Verbindungskennungen durchgeführt wird, was die Leistung beeinträchtigen kann. Beispielsweise werden in einer JDBC-Anwendung nach dem Ende einer Transaktion "Statements", "PreparedStatements" und "ResultSets" implizit geschlossen, die Verbindung bleibt jedoch gültig.
  • Es wird empfohlen, Verbindungen nicht über Transaktionsgrenzen hinweg zwischenzuspeichern. Für gemeinsam genutzte Verbindungen wird das Muster "Abrufen/Verwenden/Schließen" bevorzugt.
  • Das Zwischenspeichern von Verbindungskennungen über Servletmethoden hinweg ist auf JDBC- und JMS-Ressourcen (Java™ Message Service) beschränkt. Für andere nicht relationale Ressourcen, wie z. B. CICS- (Customer Information Control System) oder IMS-Objekte, können Verbindungskennungen derzeit nicht in einem Servlet zwischengespeichert werden. Sie müssen die Verbindungskennung bei jedem Methodenaufruf abrufen, verwenden und schließen. (Diese Einschränkung gilt nur für Servlets mit einem Thread. Servlets mit mehreren Threads lassen das Zwischenspeichern von Verbindungskennungen generell nicht zu.)
  • Eine zwischengespeicherte Verbindungskennung kann nicht von einer Instanz eines Datenzugriffsclients an eine andere Clientinstanz übergeben werden. Bei der Übertragung der Kennung zwischen den Clientinstanzen tritt der problematische Fall ein, dass eine Instanz eine Verbindungskennung verwendet, die von einer anderen Instanz referenziert wird. Diese Beziehung ist nur deshalb problematisch, weil der Verwaltungscode für Verbindungskennungen die Tasks für jede Clientinstanz separat verarbeitet. Die Übertragung von Verbindungskennung führt deshalb zu Laufzeitszenarien, die Ausnahmen auslösen. Beispiel:
    1. Der Anwendungscode einer Clientinstanz, die eine übertragene Kennung empfängt, schließt die Kennung.
    2. Wenn die Clientinstanz, die die ursprüngliche Referenz auf die Kennung enthält, die Kennung zurückfordert, setzt der Anwendungsserver eine Ausnahme ab.

Das folgende Codesegment zeigt das Muster "Zwischengespeicherte Verbindung".

Connection conn = ds.getConnection();
ut.begin();
conn.prepareStatement("....."); // Verbindung wird im Modus für globale Transaktionen ausgeführt
...
ut.commit();
conn.prepareStatement("....."); // Verbindung ist noch gültig, wird aber im Modus autoCommit(True); ausgeführt
...

Nicht gemeinsam nutzbare Verbindungen

Einige Eigenschaften von Verbindungskennungen, die mit "res-sharing-scope=unshareable" abgerufen werden, sind im Folgenden beschrieben.
  • Mögliche Vorteile nicht gemeinsam genutzter Verbindungen
    • Ihre Anwendung ist immer direkt mit der physischen Verbindung verknüpft (verwaltete Verbindung).
    • Es besteht immer eine Eins-zu-eins-Beziehung zwischen der Verbindungskennung und der verwalteten Verbindung.
    • Meistens wird die Verbindung erst dann geschlossen, wenn sie von der Anwendung geschlossen wird.
    • Sie können eine zwischengespeicherte, nicht gemeinsam genutzte Verbindung in mehreren Transaktionen verwenden.
    • Die Verbindung kann in einigen Situationen, in denen die Kennung zwischengespeichert wird, einen Leistungsvorteil bieten. Da nicht gemeinsam genutzte Verbindungen nicht den Aufwand verursachen, der beim Entfernen der Verbindungskennung von verwalteten Verbindungen am Ende der Transaktion entsteht, gibt es bei Verwendung von zwischengespeicherten, nicht gemeinsam genutzten Verbindungen insgesamt weniger Aufwand.
  • Mögliche Nachteile nicht gemeinsam genutzter Verbindungen
    • Ineffiziente Verwendung der Verbindungsressourcen. Beispiel: Wenn Sie innerhalb einer Transaktion mehrere Verbindungen (mit denselben Eigenschaften) abrufen und dabei dieselbe Datenquelle oder Verbindungsfactory (dieselbe Ressourcenreferenz) verwenden, verwenden Sie bei nicht gemeinsam nutzbaren Verbindungen mehrere physische Verbindungen.
    • Verschwendete Verbindungen. Die Verbindungskennung sollte auf keinen Fall länger als nötig geöffnet bleiben (d. h. die Anwendung ruft die Methode "close()" nicht auf). Solange eine nicht gemeinsam nutzbare Verbindung geöffnet bleibt, ist die physische Verbindung für andere Komponenten nicht verfügbar, selbst wenn Ihre Anwendung die Verbindung nicht nutzt. Anders als gemeinsam nutzbare Verbindungen wird eine nicht gemeinsam nutzbare Verbindung nicht am Ende einer Transaktion oder eines Servletaufrufs geschlossen.
    • Überlegungen zu gegenseitigem Sperren (Deadlock). Abhängig davon, wie Ihre Komponenten in einer Transaktion mit der Datenbank interagieren, kann die Verwendung nicht gemeinsam nutzbarer Verbindungen zu einem Deadlock in der Datenbank führen. Beispiel: In einer Transaktion erhält Komponente A eine Verbindung zu Datenquelle X, aktualisiert Tabelle 1, und ruft dann Komponente B auf. Komponente B erhält eine andere Verbindung zur selben Datenquelle X und aktualisiert/liest Tabelle 1 (oder noch schlimmer: sie aktualisiert/liest dieselbe Zeile wie Komponente A). Je nach Datenbank, Sperrschema und Isolationsstufe für Transaktionen kann dabei ein Deadlock auftreten.

      In demselben Szenario, allerdings mit einer gemeinsam genutzten Verbindung, kann kein Deadlock auftreten, weil die gesamte Arbeit in derselben Verbindung vorgenommen wird. Beim Schreiben von Code, der gemeinsam genutzte Verbindungen verwendet, verwenden Sie eine Strategie, die mehrere Vorgänge in derselben Verbindung und möglicherweise sogar in derselben Transaktion aufruft. Wenn Sie sich für die Verwendung einer nicht gemeinsam nutzbaren Verbindung entscheiden, müssen Sie die Eigenschaft "Maximale Anzahl der Verbindungen" für die Verbindungsfactory oder die Datenquelle korrekt definieren. Es kann eine Ausnahme bei anstehenden Verbindungsanforderungen eintreten, wenn die maximal zulässige Anzahl von Verbindungen überschritten ist und nicht gemeinsam nutzbare Verbindungen vor Ablauf des Verbindungszeitlimits nicht geschlossen werden.

Gemeinsam nutzbare Verbindungen

Einige Eigenschaften von Verbindungskennungen, die mit "res-sharing-scope=shareable" abgerufen werden, sind im Folgenden beschrieben.
  • Mögliche Vorteile gemeinsam genutzter Verbindungen
    • In einer Instanz mit gemeinsamer Nutzung von Verbindungen können Anwendungskomponenten eine verwaltete Verbindung mit einer oder mehreren Verbindungskennungen gemeinsam nutzen, wobei es darauf ankommt, wie die Kennung abgerufen wird und welche Verbindungseigenschaften verwendet werden.
    • Sie können Ressourcen effektiver verwenden. Gemeinsam nutzbare Verbindungen sind außerhalb ihrer gemeinsamen Grenze nicht gültig. Deshalb ist am Ende der gemeinsamen Grenze (z. B. der Transaktion) die Verbindungskennung nicht mehr der verwalteten Verbindung zugeordnet, die sie innerhalb der gemeinsamen Grenze verwendet hat (dies gilt nur bei Verwendung des Musters "Zwischengespeicherte Kennung"). Die verwaltete Verbindung wird zur Wiederverwendung an den Pool freier Verbindungen zurückgegeben. Verbindungsressourcen werden nicht über das Ende des Bereichs der gemeinsamen Nutzung hinweg gehalten.

      Bei Verwendung des Musters "Zwischengespeicherte Kennungen" stellt der Anwendungsserver bei der nächsten Verwendung der Kennung in einem neuen gemeinsamen Nutzungsbereich sicher, dass die Kennung wieder einer für den aktuellen Nutzungsbereich geeigneten verwalteten Verbindung zugeordnet wird, und zwar mit denselben Eigenschaften, mit denen die Kennung ursprünglich abgerufen wurde. Es ist nicht sinnvoll, die Eigenschaften einer gemeinsam nutzbaren Verbindung zu ändern. Wenn Eigenschaft geändert werden, könnte es bei anderen Komponenten, die dieselben Verbindung benutzen, zu einem unerwartetem Verhalten kommen. Außerdem könnte bei Verwendung zwischengespeicherter Kennungen der Wert der geänderten Eigenschaft nicht über die gemeinsamen Nutzungsbereiche hinaus gespeichert werden.

  • Mögliche Nachteile gemeinsam genutzter Verbindungen
    • Die gemeinsame Benutzung mit einer einzelnen Komponente (z. B. einer Enterprise-Bean und ihren zugehörigen Java-Objekten) wird nicht immer unterstützt. In der aktuellen Spezifikation ist vorgesehen, dass die Ressourcenadapter auch nur eine aktive Verbindungskennung zu lassen dürfen.
      Wenn ein Ressourcenadapter sich für die Implementierung dieser Option entscheidet, führt das folgende Szenario zu einer Ausnahme vom Typ "ungültige Kennung". Eine Komponente, die gemeinsam nutzbare Verbindungen verwendet, fordert eine Verbindung an und verwendet diese dann. Ohne die Verbindung zu schließen, ruft die Komponente eine Dienstprogrammklasse (ein Java-Objekt) auf, die eine Verbindungskennung zu derselben verwalteten Verbindung anfordert und diese verwendet. Da der Ressourcenadapter nur eine aktive Kennung unterstützt, ist die erste Verbindungskennung nicht mehr gültig. Wenn das Dienstprogrammobjekt zurückgegeben wird, ohne seine Kennung zu schließen, bleibt die erste Kennung ungültig, und ihre Verwendung führt zu einer Ausnahme.
      Anmerkung: Diese Ausnahme tritt nur auf, wenn ein Dienstprogrammobjekt (Java-Objekt) aufgerufen wird.

      Nicht alle Ressourcenadapter unterliegen dieser Einschränkung. Die Ausnahme tritt nur in bestimmten Implementierungen ein. Der Relational Resource Adapter (RRA) von WebSphere hat diese Einschränkung nicht. Alle vom RRA genutzten Datenquellen haben diese Einschränkung nicht. Wenn Sie einen Ressourcenadapter mit dieser Einschränkung verwenden, können Sie dieses Problem umgehen, indem Sie Ihre Zugriffe auf die verwaltete Verbindung serialisieren. Wenn Sie die Verbindungskennung jedes Mal schließen, bevor Sie eine neue Kennung anfordern, oder Code aufrufen, der eine neue Kennung anfordert, und die Kennung schließen, bevor Sie aus der Methode zurückkehren, können Sie es zulassen, dass zwei Teile Ihres Codes dieselbe verwaltete Verbindung gemeinsam benutzen. Es ist nur nicht möglich, die Verbindung für beide Ereignisse gleichzeitig zu verwenden.

    • Wenn Sie versuchen, die Isolationsstufe für eine JDBC-basierte, gemeinsam nutzbare Verbindung in einer globalen Transaktion zu ändern, tritt eine Ausnahme ein. Verbindungen mit unterschiedlichen Isolationsstufen für Transaktionen müssen durch Konfigurieren der erweiterten IBM® Ressourcenreferenz angefordert werden.
    • Das Schließen von Verbindungskennungen für gemeinsam nutzbare Verbindungen durch eine Anwendung wird NICHT unterstützt und verursacht Fehler. Allerdings können Sie diese Einschränkung umgehen, indem Sie den RRA verwenden.

Optimierung der bedarfsgesteuerten Verbindungszuordnung

Der Verbindungsmanager des Java EE Connector (J2C) implementiert die Unterstützung für intelligente Kennungen. Diese Technologie ermöglicht Ihnen, einer Anwendung eine Verbindungskennung zuzuordnen, während die verwaltete Verbindung, die dieser Verbindungskennung zugeordnet ist, von anderen Anwendungen verwendet wird (sofern die Verbindung nicht von der ursprünglichen Anwendung verwendet wird). Dieses Konzept ist Teil der Spezifikation Java EE Connector Architecture (JCA) 1.5. (Es ist im Spezifikationsdokument der JCA Version 1.5 im Abschnitt "Lazy Connection Association Optimization" beschrieben.) Die Unterstützung für intelligente Kennungen führt die Verwendung einer Methode für das Objekt "ConnectionManager", die Methode "LazyAssociatableConnectionManager()", und eine neue Markierungsschnittstelle, die Klasse "DissociatableManagedConnection", ein. Sie müssen den Provider des Ressourcenadapters konfigurieren, um diese Funktionalität in Ihrer Umgebung bereitzustellen. (Bei RRA ist WebSphere Application Server selbst der Provider.) Das folgende Codefragment veranschaulicht, wie Sie die Unterstützung für Kennungen auf elegante Weise einfügen:
package javax.resource.spi;
import javax.resource.ResourceException;

interface LazyAssociatableConnectionManager { // Anwendungsserver
    void associateConnection(
        Object connection, ManagedConnectionFactory mcf,
        ConnectionRequestInfo info) throws ResourceException;
}

interface DissociatableManagedConnection { // Ressourcenadapter
    void dissociateConnections() throws ResourceException;
}

Die Schnittstelle "DissociatableManagedConnection" führt einen weiteren Status für das Verbindungsobjekt ein, den Status inaktiv. Eine Verbindung kann jetzt aktiv, geschlossen und inaktiv sein. Das Verbindungsobjekt nimmt den Status "inaktiv" an, wenn ein zugehöriges ManagedConnection-Objekt bereinigt wird. Die Verbindung bleibt so lange inaktiv, bis eine Anwendungskomponente versucht, sie erneut zu verwenden. Der Ressourcenadapter sendet dann einen Rückruf an den Verbindungsmanager, um die Verbindung erneut einem aktiven ManagedConnection-Objekt zuzuordnen.


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