Verbindungspools optimieren
Mit Hilfe von Verbindungspools kann sowohl der Systemaufwand für die Verbindungsverwaltung vermindert als auch die Zahl der Entwicklungstasks für den Datenzugriff verringert werden. Wenn eine Anwendung versucht, auf einen Back-End-Datenspeicher (z. B. eine Datenbank) zuzugreifen, benötigt sie jedes Mal Ressourcen zur Erstellung, Aufrechterhaltung und zum Trennen einer Verbindung zu diesem Datenspeicher. Um den Aufwand zu verringern, den dieser Prozess bei allen Anwendungsressourcen verursachen kann, bietet der Anwendungsserver den Administratoren die Möglichkeit, einen Pool von Back-End-Verbindungen einzurichten, die von allen Anwendungen in einem Anwendungsserver gemeinsam genutzt werden können. Beim Verbindungspooling wird der Systemaufwand für die Verbindungen auf mehrere Benutzeranforderungen verteilt. Die Anwendungsressourcen werden dabei für zukünftige Anforderungen "geschont".
Informationen zu diesem Vorgang

Vorgehensweise
- Einen Verbindungs-Deadlock verhindern. Wenn die Anwendung mehrere parallele Verbindungen pro Thread erfordert und der Pool der Datenbankverbindungen für die Anzahl der Threads nicht ausreicht, kann ein Deadlock auftreten. Nehmen wir beispielsweise an, jeder Anwendungsthread erfordert zwei parallele Datenbankverbindungen und die Anzahl der Threads stimmt mit der maximalen Größe des Verbindungspools überein. Bei dieser Ausgangssituation ist mit einem Deadlock zu rechnen, wenn die beiden folgenden Bedingungen erfüllt sind:
- Jeder Thread hat seine erste Datenbankverbindung und alle Verbindungen sind in Gebrauch.
- Alle Threads warten auf eine zweite Datenbankverbindung. Es wird jedoch keine Verbindung frei, weil alle Threads blockiert sind.
Wenn Sie den Deadlock in diesem Fall vermeiden möchten, sollten Sie die Maximalzahl der Verbindungen für den Datenbankverbindungspool mindestens um den Wert 1 erhöhen. Auf diese Weise könnte mindestens einer der wartenden Threads seine zweite Datenbankverbindung abrufen und einen Deadlock vermeiden.
Um einem Verbindungs-Deadlock generell vorzubeugen, sollten Sie Ihre Anwendungen so codieren, dass sie nur eine Verbindung pro Thread verwenden. Ist die Anwendung so codiert, dass sie C parallele Datenbankverbindungen pro Thread erfordert, muss der Verbindungspool mindestens die folgende Anzahl Verbindungen unterstützen. T steht hier für die maximale Anzahl Threads:T * (C - 1) + 1
Die Einstellungen des Verbindungspools stehen in direktem Bezug zur konfigurierten Anzahl der vom Datenbankserver unterstützten Verbindungen. Wenn sich die maximale Anzahl der Verbindungen im Pool erhöht, die entsprechenden Einstellungen für die Datenbank jedoch nicht geändert werden, kann die Anwendung fehlschlagen. Die Fehlernachrichten zu den SQL-Ausnahmen werden an den folgenden Positionen angezeigt:Eine der häufigsten Ursachen für Verbindungs-Deadlocks ist die Verwendung desselben Verbindungspools für Servlets und Enterprise JavaBeans (EJBs) mit einhergehendem direkten oder indirekten Aufruf der Bean durch das Servlet. Beispiel: Ein Servlet, das eine JMS-Verbindung aus dem Verbindungspool abruft, sendet eine Nachricht an eine nachrichtengesteuerte Bean und wartet auf eine Antwort. Die nachrichtengesteuerte Bean ist so konfiguriert, dass sie denselben Verbindungspool wie das Servlet verwendet, und deshalb benötigt die nachrichtengesteuerte Bean eine weitere Verbindung, um eine Antwort an das Servlet zu senden. Servlets und Enterprise-Beans verwenden nicht denselben Verbindungspool. Dies ist ein klassischer Fall gleichzeitiger Threads, in dem die Anzahl gleichzeitiger Threads 2 und T die maximale Größe der Servlet- und EJB-Thread-Pools ist.Datei stderr.log
SYSOUT des Service
- Verbindungspooling inaktivieren.
- Fügen Sie für relationale Ressourcenadapter
(Relational Resource Adapter, RAR) die angepasste Eigenschaft
disableWASConnectionPooling für Ihre Datenquellen hinzu.
- Klicken Sie auf JDBC > Datenquellen.
- Klicken Sie auf den Namen der Datenquelle, die Sie konfigurieren möchten.
- Klicken Sie unter Weitere Eigenschaften auf Angepasste Eigenschaften.
- Klicken Sie auf Neu.
- Geben Sie die folgenden Informationen in die erforderlichen Feldern ein:
- Name: disableWASConnectionPooling
- Wert: true
- Bei anderen Ressourcenadaptern prüfen Sie die Bindespezifikationen für den betreffenden Adapter, um Ihre Anwendungen so zu konfigurieren,
dass das Verbindungspooling inaktiviert ist.
- Inaktivieren Sie das Verbindungspooling programmgesteuert über den Ressourcenadapter.
- Der Anwendungsserver verwendet den folgenden Code, um die Ausnahme
javax.resource.NotSupportedException zu finden und das Verbindungspooling zu inaktivieren:
_managedFactory.matchManagedConnections(s,subject,cri); // 169059 174269 } catch(javax.resource.NotSupportedException e){
- Fügen Sie für relationale Ressourcenadapter
(Relational Resource Adapter, RAR) die angepasste Eigenschaft
disableWASConnectionPooling für Ihre Datenquellen hinzu.
- Verzögerte Registrierung aktivieren.
In der Anwendungsserverumgebung bezeichnet der Begriff "verzögerte Registrierung" die Technik, bei der der Anwendungsserver wartet, bis die Verbindung verwendet wird, bevor er die Verbindung im Geltungsbereich seiner Arbeitseinheit registriert.
Schauen Sie sich die folgende Darstellung einer verzögerten Registrierung an:- Eine Anwendungskomponente, die die verzögerte Registrierung verwendet, ruft innerhalb einer globalen Transaktion die Methode getConnection auf.
- die Anwendungskomponente verwendet die Verbindung nicht sofort.
- Wenn die Anwendung den Aufruf zur erstmaligen Verwendung der Verbindung startet, wird dieser vom Transaktionsmanager abgefangen.
- Der Transaktionsmanager registriert die XA-Ressource für die Verbindung und ruft die Methode XAResource.start auf.
- Der Verbindungsmanager, der der XA-Ressource zugeordnet ist, sendet den Aufruf an die Datenbank.
Die verzögerte Registrierung bietet eine bessere Leistung, wenn eine Verbindung abgerufen, aber nicht im Bereich der Arbeitseinheit (UOW) verwendet wird, weil der Aufwand für die Teilnahme an einer UOW entfällt, wenn dies nicht erforderlich ist.
Sie können beim Anbieter des Ressourcenadapters nachfragen, ob der Ressourcenadapter diese Funktionalität bereitstellt. Der relationale Ressourcenadapter des Anwendungsservers unterstützt die verzögerte Registrierung automatisch.
Verzögerte Registrierung in den Code aufnehmen:
Die Spezifikation Java™ Platform, Enterprise Edition (Java EE) Connector Architecture (JCA) Version 1.5 ruft die Technik "Lazy Transaction Enlistment Optimization" für die verzögerte Registrierung auf. Diese Unterstützung wird durch eine Markierungsschnittstelle, LazyEnlistableManagedConnection, und eine neue Methode im Verbindungsmanager, LazyEnlistableConnectionManager(), realisiert:package javax.resource.spi; import javax.resource.ResourceException; import javax.transaction.xa.Xid; interface LazyEnlistableConnectionManager { // application server void lazyEnlist(ManagedConnection) throws ResourceException; } interface LazyEnlistableManagedConnection { // resource adapter }
- Gemeinsame Nutzung des Verbindungspools steuern. Sie können die angepasste Verbindungspooleigenschaft "defaultConnectionTypeOverride" oder "globalConnectionTypeOverride" für eine bestimmte Verbindungsfactory oder Datenquelle verwenden, um die gemeinsame Verbindungsnutzung zu steuern:
- Die Eigenschaft "defaultConnectionTypeOverride" ändert den Standardwert für die gemeinsame Nutzung für einen Verbindungspool. Diese Eigenschaft ermöglicht Ihnen, die gemeinsame Verbindungsnutzung für direkte Suchfunktionen zu steuern. Wenn Ressourcenreferenzen für diese Datenquelle oder Verbindungsfactory konfiguriert sind, haben die Konfigurationseinstellungen der Ressourcenreferenz Vorrang vor den Einstellungen der Eigenschaft "defaultConnectionTypeOverride". Wenn z. B. eine Anwendung direkte Suchen durchführt und keine gemeinsame Nutzung von Verbindungen gewünscht wird, setzen Sie diese Eigenschaft auf unshared.
- Der für die angepasste Eigenschaft "globalConnectionTypeOverride" angegebene Wert hat Vorrang vor allen anderen Einstellungen für die gemeinsame Nutzung von Verbindungen. Wenn Sie diese Eigenschaft beispielsweise auf unshared setzen, ist die gemeinsame Nutzung von Verbindungen für alle Verbindungsanforderungen inaktiviert, sowohl für direkte Suchvorgänge als auch für Suchvorgänge, die sich auf Ressourcenreferenzen beziehen. Diese Eigenschaft ist eine Methode, mit der Sie schnell testen können, welche Auswirkungen das Einstellen aller Verbindungen für eine bestimmte Datenquelle/Verbindungsfactory auf "unshared" oder "shared" hat, ohne Ressourcenreferenzeinstellungen zu ändern.
Wenn Sie Werte für die Eigenschaften "defaultConnectionTypeOverride" und "globalConnectionTypeOverride" angeben, wird nur der für die Eigenschaft "globalConnectionTypeOverride" angegebene Wert verwendet, um den Typ für die gemeinsame Nutzung von Verbindungen zu bestimmen.
Wenn Sie diese neuen angepassten Eigenschaften den Einstellungen für eine Datenquelle oder einem Verbindungspool einer Verbindungsfactory hinzufügen möchten, muss eine neue angepasste Verbindungspooleigenschaft erstellt werden. Verwenden Sie die Administrationskonsole, um eine dieser Eigenschaften einer Datenquelle hinzuzufügen. Klicken Sie auf Ressourcen > JDBC > Datenquellen.Wählen Sie Ihre Datenquelle in der Liste aus und klicken Sie auf Weitere Eigenschaften > Eigenschaften der Verbindungspools > Angepasste Eigenschaften für Verbindungspool > Neu. Für J2C- oder JMS-Verbindungsfactorys navigieren Sie in der Administrationskonsole zur Verbindungsfactorydefinition. Wählen Sie anschließend Weitere Eigenschaften > Verbindungspool > Angepasste Eigenschaften für Verbindungspool > Neu aus. Geben Sie anschließend defaultConnectionTypeOverride oder globalConnectionTypeOverride im Feld Name und Gemeinsam genutzt oder Keine gemeinsame Nutzung im Feld Wert ein.Wichtig: Die Eigenschaften müssen unter Angepasste Eigenschaften für Verbindungspool und nicht in den allgemeinen angepassten Eigenschaften (Angepasste Eigenschaften) der Datenquelle oder Verbindungsfactory festgelegt werden. Aktion zur Risikominderung automatisch ausführen, wenn ein Verbindungspool keine Verbindung zu seinem konfigurierten Ressourcenmanager herstellen kann.
Sie können einen Verbindungspool mit den Eigenschaften "failureNotificationActionCode" und "failureThreshold" für den Fall, dass eine Verbindungsfactory keine Verbindung zu ihrem konfigurierten Ressourcenmanager herstellen kann, so konfigurieren, dass die Laufzeit von WebSphere Application Server for z/OS eine autonome Aktion zur Risikominderung ausführt. Somit werden die Auswirkungen des Fehlers für den Benutzer in Grenzen gehalten. Wenn eine Verbindungsfactory erneut eine Verbindung zum konfigurierten Ressourcenmanager herstellen kann, wird die autonome Aktion zur Risikominderung zurückgenommen. Ein Beispiel für diese Aktion: Die Laufzeit kann einen Befehl absetzen, mit dem die Listener für den Server, auf dem sich die fehlerhafte Ressource befindet, angehalten werden, damit der Server keine neuen Anforderungen mehr akzeptiert. Bei Verwendung einer Front-End-Komponente mit hoher Verfügbarkeit können neue Arbeitsvorgänge an andere Server in einem Cluster weitergeleitet werden.
Wenn eine bestimmte Verbindungsfactory oder Datenquelle einen definierten oder standardmäßig verwendeten Fehlerschwellenwert erreicht hat, wird eine Benachrichtigung an die z/OS-Laufzeit gesendet. Die Fehlerbenachrichtigung umfasst einen konfigurierten Aktionscode, der festlegt, wie die Laufzeit auf die Fehlerbenachrichtigung reagiert. Definitionen von Aktionscodes finden Sie im Artikel "Angepasste Einstellungen des Verbindungspools".
Wenn Sie diese Eigenschaften verwenden möchten, müssen Sie sie als neue angepasste Eigenschaften des Verbindungspools definieren. Sie können das wie folgt über die Administrationskonsole tun: Klicken Sie auf JDBC-Provider > Datenquellen > Verbindungspools > Angepasste Eigenschaften > Neu. Geben Sie anschließend failureNotificationActionCode oder failureNotification im Feld Name und im Feld Wert den entsprechenden Wert an.
Weitere Informationen zu den Einstellungen für diese angepassten Eigenschaften finden Sie im Artikel "Angepasste Eigenschaften des Verbindungspools".
- Verbindungen verwerfen.
Die Einstellungen für die Bereinigungszeit und das Zeitlimit für Nichtverwendung legen nicht fest, dass inaktive oder nicht verwendete Verbindungen gelöscht werden, wenn die Servantregion inaktiv ist. Dies kann dazu führen, dass einige DB2-Verbindungen länger aufrechterhalten werden als nötig.
Wenn Sie möchten, dass die Verbindungen zu dem Zeitpunkt gelöscht werden, der durch Kombination der Einstellungen für die Bereinigungszeit und für das Zeitlimit für Nichtverwendung festgelegt wird, und wenn Sie diese Festlegung auch dann vornehmen möchten, wenn sie dazu führen könnte, dass die inaktive Servantregion erneut aktiv wird, können Sie die angepasste Eigenschaft "nondeferredreaper" in die Datenquelleneinstellungen für den JDBC Driver Provider aufnehmen. Wenn Sie diese angepasste Eigenschaft hinzufügen, werden Verbindungen zu dem durch Kombination der Einstellungen für die Bereinigungszeit und für das Zeitlimit für Nichtverwendung festgelegten Zeitpunkt gelöscht.
Um diese Eigenschaft in Ihre Datenquelleneinstellungen für den JDBC Driver Provider aufzunehmen, klicken Sie in der Administrationskonsole auf Ressourcen > JDBC-Provider > DB2 Universal JDBC Driver Provider > Datenquellen > Datenquelle > Angepasste Eigenschaften > Neu. Geben Sie anschließend nondeferredreaper im Feld Name, true im Feld Wert und java.lang.Boolean im Feld Typ an. Diese neue Einstellung tritt erst dann in Kraft, wenn Sie den Server, der diese Datenquelle verwendet, erneut starten.
Fehler vermeiden: Wenn Sie eine inaktive Servantregion nur zu dem Zweck aktivieren, nicht verwendete Verbindungen zu löschen, kann dies eine zusätzliche und manchmal unerwünschte CPU-Belastung zur Folge haben. Außerdem kann folgende Warnung protokolliert werden, die Sie ignorieren können:
gotchaDSRA8200W: DataSource-Konfiguration: DSRA8020E: Warnung: Die Eigenschaft 'nondeferredreaper' ist nicht in der DataSource-Klasse classcom.ibm.db2.jcc.DB2ConnectionPoolDataSource enthalten.
- Verbindungspools basierend auf der Bereinigungsrichtlinie bereinigen.
Wenn das Fehlererkennungsmodell für die Ausnahmezuordnung konfiguriert ist, zeigt die Ausnahme für veraltete Verbindungen an, dass die Verbindung nicht mehr gültig ist.
Wenn beim Ausnahmezuordnungsprozess eine StaleConnectionException ausgelöst wird, wird ein Verbindungsfehlerereignis ausgelöst, und infolgedessen wird der Verbindungspool bereinigt. In diesem Fall jedoch wird die StaleConnectionException instanziiert, der vorhandene Code hat nicht die Funktionalität für das Auslösen des Verbindungsfehlerereignisses, und der Pool wird nicht bereinigt. Wenn Verbindungen beim Anfordern einer neuen Verbindung datenbankseitig beendet werden, löst der Treiber eine XAException aus. Wenn das zum Ergebnis errorDetectionModel=ExceptionMapping führt, wird ein ConnectionErrorEvent ausgelöst, sodass der Verbindungspool basierend auf der Bereinigungsrichtlinie bereinigt wird.
Um diese Eigenschaft in Ihre Datenquelleneinstellungen für den JDBC Driver Provider aufzunehmen, klicken Sie in der Administrationskonsole auf Ressourcen > JDBC-Provider > DB2 Universal JDBC Driver Provider > Datenquellen > Datenquelle > Angepasste Eigenschaften > Neu. Geben Sie anschließend fireCEEventOnSCE im Feld Name, true im Feld Wert und java.lang.Boolean im Feld Typ an. Diese neue Einstellung tritt erst dann in Kraft, wenn Sie den Server, der diese Datenquelle verwendet, erneut starten.
Der WebSphere-RRA-Code wurde so geändert, dass der Pool bei einer StaleConnectionException ordnungsgemäß bereinigt wird, wenn als Fehlererkennungsmodell die Ausnahmezuordnung verwendet wird.
Unterartikel


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tdat_conpoolman
Dateiname:tdat_conpoolman.html