Service für das Testen von Verbindungen
WebSphere Application Server stellt einen Service für Verbindungstests bereit, mit dem Datenquellenkonfigurationen validiert werden können. Die Operation "testConnection" instanziert die Datenquellenkonfiguration, ruft eine Verbindung ab und schließt die Verbindung dann sofort wieder.
Wenn die Definition Ihrer Datenquelle eine WebSphere-Variable enthält, müssen Sie feststellen, wie sich die Einstellungen für den Geltungsbereich der Variablen und der Datenquelle auf die Ergebnisse des Verbindungstests auswirken. Der nächste Schritt ist die Auswahl einer der drei Methoden zum Starten des Verbindungstests. Sie können den Service in der Administrationskonsole, mit dem Tool "wsadmin" oder mit einem eigenständigen Java™-Programm aktivieren.
Einstellungen für den Geltungsbereich überprüfen
Wenn Sie den WebSphere-Variablen Ihre Datenquellenkonfigurationen zuordnen, können Ergebnisse des Verbindungstests inkongruent mit dem tatsächlichen Laufzeitverhalten Ihrer Anwendung sein. In manchen Fällen schlägt die Operation zum Testen der Verbindung fehl, aber die physische Datenquelle funktioniert während der Ausführung der Anwendung ordnungsgemäß. Der potenzielle Konflikt ist darauf zurückzuführen, dass der Anwendungsserver die Einstellungen der WebSphere-Variablen für den Geltungsbereich zur Laufzeit anders behandelt als während des Verbindungstests. Wenn Sie diesen Unterschied verstehen, dann können Sie erfolgreich Datenquellenkonfigurationen erstellen.
- Der Geltungsbereich der Variablen kann die Datenquellenkonfiguration enthalten, d. h. die Variable hat den größeren Geltungsbereich.
- Die Variable und die Datenquelle haben identische Geltungsbereiche.
Geltungsbereich der Datenquelle | JVM, in der die Testverbindungsoperation ausgeführt wird |
---|---|
Zelle | Manager-Prozess |
Knoten | Node-Agent-Prozess (des relevanten Knotens) |
Cluster | Node Agent für jeden Knoten, der ein Cluster-Member enthält |
Server | Server. Sollte der Server nicht verfügbar sein, wird die Operation im Node Agent des Knotens wiederholt, der den Anwendungsserver enthält. |
![[z/OS]](../images/ngzos.gif)
- IBM Data Server Driver for JDBC and SQLJ Data Source with Driver Type 2
- DB2 Universal JDBC Driver Provider Data Source with Driver Type 2
java.sql.SQLException: Failure in loading T2 native library db2jcct2DSRA0010E: SQL state = null, Error Code = -99,999
In
manchen Fällen kann auch eine Fehlermeldung wie die folgende ausgegeben werden:T2zOS exception: [jcc][T2zos]T2zosReusableConnection.flowConnect:initRRSAFAttach
:2528: Connection dead
Beide Datenquellen basieren auf JDBC-Treibern des Typs 2, die Zugriff auf die nativen Bibliotheken des Typs 2 benötigen.
Die Laufzeitumgebung für den Anwendungsserver bietet diesen Zugriff für Datenquellen in einem Serverprozess, doch der Service für Verbindungstests
ermöglicht keinen Zugriff auf diese nativen Dateien, wenn er im Node-Agent-Prozess
ausgeführt wird.Daher können Sie, wenn Sie diese Datenquellen auf Knoten- oder Clusterebene erstellen, dieselben Konfigurationen vorübergehend zu Testzwecken auf Serverebene erstellen. Führen Sie die Testverbindungsoperation auf Serverebene aus, um festzustellen, ob die Datenquelleneinstellungen für Ihre Gesamtkonfiguration gültig sind.
Geltungsbereich der Datenquelle | Variablen auf Zellenebene | Variablen auf Knotenebene | Variablen auf Serverebene |
---|---|---|---|
Zellenebene | OK | Fehlgeschlagen | Fehlgeschlagen |
Knotenebene | OK | OK | Fehlgeschlagen |
Serverebene | OK | OK | OK |
Entgegen den Erwartungen führen diese Fehler beim Verbindungstest normalerweise nicht zu Laufzeitfehlern. Vergewissern Sie sich, dass die Speicherposition Ihrer JDBC-Treiberdateien für jeden Client zugänglich ist, der die Datenquelle verwenden muss, und konfigurieren Sie die WebSphere-Variable mit dem vollständigen Pfad dieser Speicherposition.
Eine der Geltungsbereichskombinationen, die in Tabelle 2 aufgelistet sind, kann jedoch ein gegenteiliges Szenario erzeugen: Der Verbindungstest ist erfolgreich, aber zur Laufzeit treten Datenquellenfehler auf. Diese Unregelmäßigkeit tritt auf, wenn eine auf Zellenebene definierte Datenquelle verwendet wird, die eine auf Zellenebene definierte WebSphere-Variable nutzt. Der Verbindungstest ist erfolgreich, weil die Operation im Deployment-Manager-Prozess stattfindet (wie in Tabelle 1 angegeben), wo Application Server die Variable auf Zellenebene auflösen kann. Die Datenquelle kann jedoch zur Laufzeit fehlschlagen, weil die Variable auf Zellenebene mit einem Nullwert überschrieben werden kann.
Wenn Sie einen Knoten erstellen, erstellt Application Server Umgebungsvariablen für alle unterstützten JDBC-Treiber auf der Knotenebene und initialisiert jede Variable mit einer leeren Zeichenfolge. Weil ein Anwendungsserver versucht, die Variablen innerhalb des Geltungsbereichs von unten nach oben aufzulösen, wird die Variable auf Zellenebene zur Laufzeit durch die Variable auf Knotenebene überschrieben. Der Server liest die leere Zeichenfolge und akzeptiert sie als Klassenpfad des JDBC-Treibers. Der Klassenpfad mit dem Nullwert löst eine Ausnahme des Typs classNotFound aus, wenn der Server versucht, die Datenquelle zu verwenden.
Sie können mit einer der Verwaltungsoptionen von Application Server verhindern, dass die leere Zeichenfolge von der Variablen für den Treiberklassenpfad als Endwert akzeptiert wird.
- In der Administrationskonsole von WebSphere Application Server: Der Assistent für Datenquellen
kopiert den Wert der Variablen auf Zellenebene
(den Sie im Erstellungsassistenten für den JDBC-Provider angeben)
in die gleichnamige Variable auf Knotenebene. Der Assistent führt die Kopieroperation nur dann aus, wenn der Wert
der Variable auf Knotenebene eine leere Zeichenfolge ist.
Dadurch wird verhindert, dass ein gültiger Klassenname, den Sie vorher angegeben haben,
geändert wird.Führen Sie diese Schritte aus, um sicherzustellen, dass die Datenquelle zur Laufzeit ordnungsgemäß mit der Variablen auf Knotenebene funktioniert:
- Installieren Sie die JDBC-Treiberdateien auf dem Deployment-Manager-Knoten und auf jedem anderen Knoten, auf dem die Datenquelle funktionieren soll.
- Verwenden Sie den Pfad der Treiberdatei im Deployment Manager, um die WebSphere-Variable für einen JDBC-Provider auf Zellenebene zu definieren.
- Stellen Sie sicher, dass die Datenquelle dem JDBC-Provider des Deployment Manager
zugeordnet ist und dieselbe Zellenebene hat.Wichtig: Damit diese Operation erfolgreich ist, müssen Sie die Treiberdateien in Speicherpositionen installieren, deren vollständige Pfadnamen auf allen Knoten, einschließlich des Deployment-Manager-Knotens, identisch sind. Andernfalls kann dasselbe Szenario wie zuvor die Folge sein: Die Testverbindung ist erfolgreich, aber in der Laufzeit treten Fehler auf.
- Im Scripting-Tool wsadmin: Damit die Datenquelle sowohl
während des Verbindungstests als auch während der Laufzeit ordnungsgemäß funktioniert,
erstellen Sie sowohl auf der Zellenebene als auch
auf allen relevanten Knotenebenen dieselben Konfigurationen für den Treiberklassenpfad. Gehen Sie wie folgt vor:
- Installieren Sie die JDBC-Treiberdateien auf dem Deployment-Manager-Knoten. Verwenden Sie diesen Pfadnamen, um die Variable für den Treiberklassenpfad für einen JDBC-Provider auf Zellenebene zu definieren.
- Stellen Sie sicher, dass die Datenquelle dem JDBC-Provider des Deployment Manager zugeordnet ist und dieselbe Zellenebene hat.
- Installieren Sie auf jedem Knoten, auf dem die Datenquelle funktionieren soll,
die JDBC-Treiberdateien, und verwenden Sie diesen Pfad, um die WebSphere-Variable für einen JDBC-Provider auf
Knotenebene zu definieren. Jeder Provider muss dieselbe Konfiguration haben.Wichtig: Damit diese Operation erfolgreich ist, müssen Sie die Treiberdateien in Speicherpositionen installieren, deren vollständige Pfadnamen auf allen Knoten, einschließlich des Deployment-Manager-Knotens, identisch sind. Andernfalls kann dasselbe Szenario wie zuvor die Folge sein: Die Testverbindung ist erfolgreich, aber in der Laufzeit treten Fehler auf.
Verwenden Sie nur dann Ressourcen auf Zellenebene, wenn alle Knoten, die Zugriff auf die Datenquelle benötigen, einschließlich des Deployment-Manager-Knotens, auf derselben Plattform ausgeführt werden und ihre JDBC-Treiber in demselben Pfad installiert sind. Andernfalls sollten Sie als größten Geltungsbereich für Ihre Datenquellen die Knotenebene verwenden.
Lookup-Operationen für Variablen umgehen
Sie können Lookup-Operationen für Umgebungsvariablen umgehen, indem Sie die Klassenpfadeinträge für den JDBC-Provider in fest codierte Werte ändern. Diese Strategie ist jedoch nur dann erfolgreich, wenn der Klassenpfad auf allen Knoten, auf denen die Datenquelle funktionieren muss, identisch konfiguriert ist.
Service für das Testen von Verbindungen aktivieren
Der Service für das Testen von Verbindungen kann auf drei Arten aktiviert werden: in der Administrationskonsole, mit dem Tool wsadmin und mit einem eigenständigen Java-Programm. Jeder Prozess ruft dieselben Methoden für dieselbe MBean auf.
Administrationskonsole
WebSphere Application Server gibt Ihnen die Möglichkeit, eine Verbindung zu testen, indem Sie in der Administrationskonsole einfach auf die Schaltfläche Verbindungen testen klicken, die auf den Seiten Datenquellen, Einstellungen für Datenquellen, Datenquellen der Version 4 und Einstellungen für Datenquellen der Version 4 angezeigt wird. Nachdem Sie eine Datenquelle definiert und gespeichert haben, können Sie auf diese Schaltfläche klicken, um sicherzustellen, dass die Parameter in der Definition der Datenquelle korrekt sind. Auf der Seite "Datenquellen" können Sie mehrere Datenquellen auswählen und diese alle gleichzeitig testen. Dazu müssen jedoch einige Vorbedingungen erfüllt sein. Weitere Informationen finden Sie im Artikel "Verbindung über die Administrationskonsole testen".
Test connection failed for data source isagent on server server1 at node
svtaix24Node01 with the following exception: java.lang.Exception:
java.sql.SQLException: JZ006: Caught IOException: java.net.ConnectException: A
remote host refused an attempted connect operation.DSRA0010E: SQL State = JZ006,
Error Code = 0
Diese Ausnahme wird ausgelöst, wenn die Portnummer
der Sybase-Datenquelle nicht mit dem im Sybase-Server konfigurierten Port übereinstimmt. Die Standardportnummer ist
5000. Überprüfen Sie die Portnummer Ihres
Sybase-Servers in der Datei "interfaces"
im /<Sybase-Installationsverzeichnis>.Tool wsadmin
Das Tool wsadmin stellt eine Scripting-Schnittstelle für eine Reihe von Administrationsaktivitäten in WebSphere Application Server bereit. Da die Funktion zum Testen von Verbindungen als Methode in einer MBean implementiert wird und das Tool wsadmin MBean-Methoden aufrufen kann, können Sie wsadmin zum Testen von Verbindungen zu Datenquellen verwenden. Für das Testen einer Datenquellenverbindung mit wsadmin stehen zwei Optionen zur Verfügung:
Das wsadmin-Objekt AdminControl kann die Operation "testConnection" ausführen, um die Konfigurationseigenschaften eines Datenquellenobjekts zu testen. Weitere Informationen hierzu finden Sie im Artikel "Verbindung mit wsadmin testen.
Schließlich können Sie eine Verbindung auch durch Aufruf der MBean-Operation testen. Der Artikel "Beispiel: Datenquellenverbindung mit wsadmin testen" enthält Richtlinien für die Anwendung dieser Technik.
Eigenständiges Java-Programm
Sie können eine Verbindung schließlich auch durch Ausführen der Methode testConnection in der MBean DataSourceCfgHelper testen. Mit dieser Methode können Sie die Konfigurations-ID der konfigurierten Datenquelle übergeben. Das Java-Programm stellt für den Zugriff auf die MBean eine Verbindung zu einem aktiven JMX-Server (Java Management Extensions) her. In einer Installation von WebSphere Application Server Network Deployment stellen Sie die Verbindung zum JMX-Server her, der im Deployment Manager in der Regel an Port 8879 ausgeführt wird.
Der Rückgabewert dieses Aufrufs kann 0, eine positive Zahl oder eine Ausnahme sein. Der Wert 0 zeigt an, dass die Operation ohne Warnungen ausgeführt wurde. Eine positive Zahl zeigt an, dass die Operation mit einer Reihe von Warnungen ausgeführt wurde. Eine Ausnahme zeigt an, dass der Verbindungstest fehlgeschlagen ist.
Der folgende Beispielcode erstellt eine Datenquelleninstanz und eine zugehörige Verbindungsinstanz und testet sie, um die Datenbankkonnektivität sicherzustellen.
Dieses Programm verwendet JMX, um die Verbindung zu einem aktiven Server herzustellen und die Methode testConnection in der MBean DataSourceCfgHelper aufzurufen. Das Akronym ND in einer Kommentarzeile zeigt, dass der folgende Code für WebSphere Application Server WebSphere Application Server Network Deployment. Das Akronym Base in einer Kommentarzeile zeigt, dass der folgende Code für WebSphere Application Server gilt.
/**
* Beschreibung
* Das Testprogramm für den Ressourcenadapter gewährleistet, dass die
* MBean-Schnittstellen funktionieren.
* Folgende Schnittstellen werden getestet:
*
* --- testConnection()
*
*
* Folgende Einstellungen müssen im Klassenpfad vorgenommen werden:
* C:\src>java -Djava.ext.dirs=C:\WebSphere\AppServer\lib;C:\WebSphere\AppServer\java\jre\lib\ext testDSGUI
* jre für log.jar und mail.jar angeben, andernfalls wird eine Ausnahme vom Typ "Klasse nicht gefunden" ausgelöst.
*
*
*/
import java.util.Iterator;
import java.util.Locale;
import java.util.Properties;
import java.util.Set;
import javax.management.InstanceNotFoundException;
import javax.management.MBeanException;
import javax.management.MalformedObjectNameException;
import javax.management.ObjectName;
import javax.management.RuntimeMBeanException;
import javax.management.RuntimeOperationsException;
import com.ibm.websphere.management.AdminClient;
import com.ibm.websphere.management.AdminClientFactory;
import com.ibm.ws.rsadapter.exceptions.DataStoreAdapterException;
public class testDSGUI {
// Port 8880 für die Basisinstallation oder Port 8879 für die ND-Installation verwenden
String port = "8880";
// String port = "8879";
String host = "localhost";
final static boolean verbose = true;
// eine Konfigurations-ID für eine Datenquelle, die für die Basis auf Knotenebene deklariert wird
private static final String resURI = "cells/cat/nodes/cat|resources.xml#DataSource_1";
// eine Datenquelle der Version 4.0, die für die Basis auf Knotenebene deklariert wird
// private static final String resURI = "cells/cat/nodes/cat|resources.xml#WAS40DataSource_1";
// z. B. Apache-Derby-Datenquelle, die für die Basis auf Serverebene deklariert wird
//private static final String resURI = "cells/cat/nodes/cat/servers/server1/resources.xml#DataSource_6";
// Datenquelle auf Knotenebene für ND
//private static final String resURI = "cells/catNetwork/nodes/cat|resources.xml#DataSource_1";
// Datenquelle auf Serverebene für ND
//private static final String resURI = "cells/catNetwork/nodes/cat/servers/server1|resources.xml#DataSource_4";
// Datenquelle auf Zellenebene für ND
//private static final String resURI = "cells/catNetwork|resources.xml#DataSource_1";
public static void main(String[] args) {
testDSGUI cds = new testDSGUI();
cds.run(args);
}
/**
* Diese Methode testet die ResourceMbean.
*
* @param args
* @exception Exception
*/
public void run(String[] args) {
try {
System.out.println("Verbindungs zum Server wird hergestellt.......");
/*************************************************************************/
/** AdminClient initialisieren */
/*************************************************************************/
Properties adminProps = new Properties();
adminProps.setProperty(AdminClient.CONNECTOR_TYPE, AdminClient.CONNECTOR_TYPE_SOAP);
adminProps.setProperty(AdminClient.CONNECTOR_HOST, host);
adminProps.setProperty(AdminClient.CONNECTOR_PORT, port);
AdminClient adminClient = null;
try {
adminClient = AdminClientFactory.createAdminClient(adminProps);
} catch (com.ibm.websphere.management.exception.ConnectorException ce) {
System.out.println("NLS: Cannot make a connection to the application server\n");
ce.printStackTrace();
System.exit(1);
}
/*************************************************************************/
/** Mbean suchen */
/*************************************************************************/
ObjectName handle = null;
try {
// Locator-Zeichenfolge senden
// dies reicht für eine Basisinstallation
ObjectName queryName = new ObjectName("WebSphere:type=DataSourceCfgHelper,*");
// für ND müssen Sie angeben, vom welchem Knoten/Prozess aus Sie testen möchten
// Beispiel für Ausführung im Server
//ND: ObjectName queryName = new ObjectName
("WebSphere:cell=catNetwork,node=cat,process=server1,type=DataSourceCfgHelper,*");
// Beispiel für Ausführung im Node Agent
//ND: ObjectName queryName = new ObjectName
("WebSphere:cell=catNetwork,node=cat,process=nodeagent,type=DataSourceCfgHelper,*");
//ND: Beispiel für Ausführung im Deployment Manager
//ND: ObjectName queryName = new ObjectName
("WebSphere:cell=catNetwork,node=catManager,process=dmgr,type=DataSourceCfgHelper,*");
Set s = adminClient.queryNames(queryName, null);
Iterator iter = s.iterator();
while (iter.hasNext()) {
// Die erste gefundene MBean verwenden.
handle = (ObjectName) iter.next();
System.out.println("Found this ->" + handle);
}
if (handle == null) {
System.out.println("NLS: Did not find this MBean>>" + queryName);
System.exit(1);
}
} catch (MalformedObjectNameException mone) {
System.out.println("Check the program variable queryName" + mone);
} catch (com.ibm.websphere.management.exception.ConnectorException ce) {
System.out.println("Cannot connect to the application server" + ce);
}
/*************************************************************************/
/** An MBean zu übergebende Build-Parameter */
/*************************************************************************/
String[] signature = { "java.lang.String" };
Object[] params = { resURI };
Object result = null;
if (verbose) {
System.out.println("\nTesting connection to the database using " + handle);
}
try {
/*************************************************************************/
/** Verbindung zur Datenbank testen */
/*************************************************************************/
result = adminClient.invoke(handle, "testConnection", params, signature);
} catch (MBeanException mbe) {
// ****** alle Benutzerausnahmen hier einfügen
if (verbose) {
Exception ex = mbe.getTargetException(); // this is the real exception from the Mbean
System.out.println("\nNLS:Mbean Exception was received contains " + ex);
ex.printStackTrace();
System.exit(1);
}
} catch (InstanceNotFoundException infe) {
System.out.println("Cannot find " + infe);
} catch (RuntimeMBeanException rme) {
Exception ex = rme.getTargetException();
ex.printStackTrace(System.out);
throw ex;
} catch (Exception ex) {
System.out.println("\nUnexpected Exception occurred: " + ex);
ex.printStackTrace();
}
/*************************************************************************/
/** Ergebnis verarbeiten. Das Ergebnis ist die Anzahl ausgegebener */
/** Warnungen. Das Ergebnis null zeigt eine erfolgreiche Verbindung */
/** (ohne Warnungen) an. */
/*************************************************************************/
//Das Ergebnis null zeigt eine erfolgreiche Verbindung (ohne Warnungen) an.
System.out.println("Result= " + result);
} catch (RuntimeOperationsException roe) {
Exception ex = roe.getTargetException();
ex.printStackTrace(System.out);
} catch (Exception ex) {
System.out.println("General exception occurred");
ex.printStackTrace(System.out);
}
}
}