Der DB2 Universal JDBC-Treiber unterstützt Konnektivität des Typs 4 zu DB2 für VM/VSE-Datenbanken nicht. In den Themen zum Konfigurieren der Windows Java-Umgebung und zum Installieren des DB2 Universal JDBC-Treibers im Handbuch Application |Development Guide: Programming Client Applications und in Information - Unterstützung von DB2 UDB wird fälschlicherweise angegeben, dass der DB2 Universal JDBC-Treiber Konnektivität des Typs 4 zu DB2 für VM/VSE-Datenbanken unterstützt.
Java-Anwendungen, die über die DB2 Universal JDBC-Treiber Type 4-Konnektivität auf DB2 UDB für z/OS(R)-Server zugreifen, können die zugehörigen Verbindungskonzentrator- und Sysplex-Funktionen für den Lastausgleich nutzen.
Diese Funktionen ähneln den Verbindungskonzentrator- und Sysplex-Funktionen für Lastausgleich von DB2 Connect.
Der Verbindungskonzentrator für den DB2 Universal JDBC-Treiber kann die Ressourcen reduzieren, die DB2 UDB für z/OS(R)-Datenbankserver zur Unterstützung einer großen Anzahl Clientanwendungen benötigen. Dies geschieht, indem viele Verbindungsobjekte dieselbe physische Verbindung verwenden dürfen. Dadurch verringert sich die Gesamtzahl physischer Verbindungen zum Datenbankserver.
Der Sysplex-Lastausgleich für DB2 Universal JDBC-Treiber kann die Verfügbarkeit einer Gruppe mit gemeinsamer Datennutzung verbessern, da der Treiber häufige Statusinformationen zu den Mitgliedern einer solchen Gruppe erhält. Der Treiber bestimmt anhand dieser Informationen das Mitglied der Gruppe mit gemeinsamer Datennutzung, an das die nächste Transaktion weitergeleitet werden soll. Über den Sysplex-Lastausgleich stellen der DB2 UDB für z/OS-Server und der Workload Manager für z/OS (WLM) sicher, dass die Last zwischen Mitgliedern der Gruppe mit gemeinsamer Datennutzung effizient verteilt und dass die Last bei Ausfall eines Mitglieds einer Gruppe mit gemeinsamer Datennutzung an die anderen Mitglieder dieser Gruppe übertragen wird.
Der DB2 Universal JDBC-Treiber verwendet Transportobjekte und einen globalen Transportobjektpool, damit der Verbindungskonzentrator- und Sysplex-Lastausgleich unterstützt wird. Für jede physische Verbindung zum Datenbankserver gibt es ein einziges Transportobjekt. Wenn Sie den Verbindungskonzentrator- und Sysplex-Lastausgleich aktivieren, können Sie die maximale Anzahl physischer Verbindungen zum Datenbankserver zu einem beliebigen Zeitpunkt festlegen, indem Sie die maximale Anzahl Transportobjekte festlegen.
Für die Anzahl Transportobjekte legen Sie auf Treiberebene mit Hilfe der Konfigurationsmerkmale des DB2 Universal JDBC-Treibers Grenzen fest.
Auf Verbindungsebene aktivieren und inaktivieren Sie für den DB2 Universal JDBC-Treiber den Verbindungskonzentrator- und Sysplex-Lastausgleich und legen Grenzen für die Anzahl Transportobjekte fest. Dazu verwenden Sie die DataSource-Merkmale.
Sie können den globalen Transportobjektpool auf eine der folgenden Arten überwachen:
Jedes der folgenden Konfigurationsmerkmale wird für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet.
Der Datentyp von db2.jcc.dumpPool ist eine ganze Zahl (int.). Die Konfigurationsmerkmale db2.jcc.dumpPoolStatisticsOnSchedule und db2.jcc.dumpPoolStatisticsOnScheduleFile müssen für das Schreiben von Statistiken ebenfalls festgelegt werden, noch bevor Statistiken geschrieben werden.
Sie können für das Merkmal db2.jcc.dumpPool folgende Statistiktypen angeben:
Wenn Sie einen Trace für mehrere Ereignistypen durchführen möchten, fügen Sie die Werte für diese Ereignistypen hinzu. Nehmen Sie z. B. einmal an, Sie möchten einen Trace für die Ereignisse DUMP_GET_OBJECT und DUMP_CREATE_OBJECT durchführen. Die numerischen Entsprechungen dieser Werte sind 2 und 16. Also geben Sie als Wert für db2.jcc.dumpPool die Zahl 18 an.
Der Standardwert ist 0, d. h., für den globalen Transportpool werden nur Zusammenfassungstatistiken geschrieben.
Der Standardwert lautet -1, d. h., die Statistikdaten für den globalen Transportpool werden nicht überschrieben.
Wenn das Konfigurationsmerkmal db2.jcc.dumpPoolStatisticsOnScheduleFile nicht angegeben ist, werden die Statistikdaten für den globalen Transportpool nicht geschrieben.
Der Standardwert für das Konfigurationsmerkmal db2.jcc.maxTransportObjectIdleTime beträgt 60. Wenn Sie das Konfigurationsmerkmal b2.jcc.maxTransportObjectIdleTime auf einen Wert unter 0 setzen, werden nicht verwendete Transportobjekte sofort aus dem Pool gelöscht. Diese Aktion wird nicht empfohlen, da sie hohe Leistungseinbußen verursachen kann.
Der Standardwert für das Konfigurationsmerkmal db2.jcc.maxTransportObjectWaitTime beträgt -1. Ein negativer Wert bedeutet, dass Anwendungen unbegrenzte Zeit warten.
Der Standardwert für das Konfigurationsmerkmal db2.jcc.maxTransportObjects beträgt -1. Dies bedeutet, dass es für die Anzahl Transportobjekte im globalen Transportobjektpool keinen Grenzwert gibt.
Der Standardwert für das Konfigurationsmerkmal db2.jcc.minTransportObjects beträgt 0. Alle Werte kleiner-gleich 0 bedeuten, dass der globale Transportobjektpool leer werden kann.
Jedes der folgenden DataSource-Merkmale für den DB2 Universal JDBC-Treiber wird für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet.
Der Datentyp des Merkmals enableConnectionConcentrator ist Boolean. Der Standardwert ist false. Wenn jedoch enableSysplexWLB auf true gesetzt ist, lautet der Standardwert true.
Der Datentyp des Merkmals enableSysplexWLB ist Boolean. Der Standardwert ist false. Wenn enableSysplexWLB jedoch auf true gesetzt ist, wird enableConnectionConcentrator standardmäßig auf true gesetzt.
Der Datentyp dieses Merkmals ist eine ganze Zahl (int.).
Wenn der Wert für maxTransportObjects nicht erreicht wurde und wenn im globalen Transportobjektpool kein Transportobjekt verfügbar ist, erstellt der Pool ein neues Transportobjekt. Wenn der Wert für maxTransportObjects erreicht ist, wartet die Anwendung während der Zeitspanne, die im Konfigurationsmerkmal db2.jcc.maxTransportObjectWaitTime angegeben ist. Wenn diese Zeitspanne vorbei ist und im Pool immer noch kein Transportobjekt verfügbar ist, löst der Pool eine SQLException aus.
Das Merkmal maxTransportObjects überschreibt das Konfigurationsmerkmal db2.jcc.maxTransportObjects nicht. Das Merkmal maxTransportObjects wirkt sich nicht auf Verbindungen von anderen DataSource-Objekten aus. Wenn der Wert für maxTransportObjects größer ist als der Wert für db2.jcc.maxTransportObjects, erhöht der Wert für maxTransportObjects den Wert für db2.jcc.maxTransportObjects nicht.
Der Standardwert für das Merkmal maxTransportObjects beträgt -1. Dies bedeutet, dass die Anzahl der Transportobjekte für DataSource nur durch den Wert für db2.jcc.maxTransportObjects für den Treiber begrenzt wird.
Die folgende Vorgehensweise ist ein Beispiel für die Aktivierung der Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion für den DB2 Universal JDBC-Treiber bei WebSphere(R) Application Server.
Servervoraussetzungen:
Clientvoraussetzungen:
Gehen Sie wie folgt vor, um die Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion für den DB2 Universal JDBC-Treiber bei WebSphere Application Server zu aktivieren:
java com.ibm.db2.jcc.DB2Jcc -versionSuchen Sie in der Ausgabe eine Zeile ähnlich der Folgenden:
[ibm][db2][jcc] Driver: IBM DB2 JDBC Universal Driver Architecture n nDabei steht n für eine Versionsnummer ab 2.7.
Legen Sie die Konfigurationsmerkmale in der Datei DB2JccConfiguration.properties fest.
db2.jcc.minTransportObjects=0 db2.jcc.maxTransportObjects=1500 db2.jcc.maxTransportObjectWaitTime=-1 db2.jcc.dumpPool=0 db2.jcc.dumpPoolStatisticsOnScheduleFile= /home/WAS/logs/srv1/poolstats
Legen Sie in der WebSphere Application Server-Verwaltungskonsole die folgenden Merkmale für die Datenquelle fest, die die Anwendung zum Herstellen der Verbindung zum Datenbankserver verwendet:
Zur Überwachung der Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion für den DB2 Universal JDBC-Treiber müssen Sie den globalen Transportobjektpool überwachen. Sie können den globalen Transportobjektpool auf eine der folgenden Arten überwachen:
Die Konfigurationsmerkmale db2.jcc.dumpPool, db2.jcc.dumpPoolStatisticsOnSchedule und db2.jcc.dumpPoolStatisticsOnScheduleFile steuern die Traceverarbeitung des globalen Transportobjektpools.
Zum Beispiel führen die folgenden Konfigurationsmerkmale dazu, dass Sysplex-Fehlernachrichten und Nachrichten über Speicherauszugspoolfehler alle 60 Sekunden in eine Datei mit dem Namen /home/WAS/logs/srv1/poolstats geschrieben werden:
db2.jcc.dumpPool=DUMP_SYSPLEX_MSG|DUMP_POOL_ERROR db2.jcc.dumpPoolStatisticsOnSchedule=60 db2.jcc.dumpPoolStatisticsOnScheduleFile=/home/WAS/logs/srv1/poolstats
Ein Eintrag in der Poolstatistikdatei sieht wie folgt aus:
uhrzeit Scheduled PoolStatistics npr:2575 nsr:2575 lwroc:439 hwroc:1764 coc:372 aooc:362 rmoc:362 nbr:2872 tbt:857520 tpo:10
Die Felder haben die folgenden Bedeutungen:
Sie können Anwendungen schreiben, um Statistikdaten zum globalen Transportobjektpool zu erfassen. Derartige Anwendungen erstellen Objekte in der Klasse DB2PoolMonitor und rufen Daten zum Pool mit Hilfe von Methoden ab.
Der folgenden Code erstellt z. B. ein Objekt zur Überwachung des globalen Transportobjektpools:
import com.ibm.db2.jcc.DB2PoolMonitor; DB2PoolMonitor transportObjectPoolMonitor = DB2PoolMonitor.getPoolMonitor (DB2PoolMonitor.TRANSPORT_OBJECT);
Nach der Erstellung des DB2PoolMonitor-Objekts können Sie die folgenden Methoden verwenden, um den globalen Transportobjektpool zu überwachen.
public int getMonitorVersion()
Ruft die Version der DB2PoolMonitor-Klasse ab, die mit dem DB2 Universal JDBC-Treiber ausgeliefert wird.
public int totalRequestsToPool()
Ruft die Gesamtzahl der Anforderungen ab, die der DB2 Universal JDBC-Treiber seit der Poolerstellung an den Pool gesendet hat.
public int successfullRequestsFromPool()
Ruft die Anzahl erfolgreicher Anforderungen ab, die der DB2 Universal JDBC-Treiber seit der Poolerstellung an den Pool gesendet hat. Eine erfolgreiche Anforderung bedeutet, dass der Pool ein Objekt zurückgegeben hat.
public int numberOfRequestsBlocked()
Ruft die Anzahl der Anforderungen ab, die der DB2 Universal JDBC-Treiber an den Pool gesendet hat und die der Pool wegen bereits belegter maximaler Kapazität blockiert hat. Eine blockierte Anforderung kann erfolgreich sein, falls ein Objekt an den Pool zurückgegeben wird, bevor der Konfigurationswert für db2.jcc.maxTransportObjectWaitTime überschritten und eine Ausnahmebedingung ausgelöst wird.
public long totalTimeBlocked()
Ruft die Gesamtzeit in Millisekunden ab, während der der Pool Anforderungen blockiert hat. Wenn die Anwendung mehrere Threads verwendet, kann diese Zeitdauer viel größer sein als die Ausführungszeit der Anwendung.
public int lightWeightReusedObjectCount()
Ruft die Anzahl der Objekte ab, die wiederverwendet wurden, jedoch nicht im Pool waren. Dieser Fall kann eintreten, wenn ein Verbindungsobjekt an einer Transaktionsgrenze ein Transportobjekt freigibt. Wenn das Verbindungsobjekt später ein Transportobjekt benötigt und wenn das ursprüngliche Transportobjekt von keinem anderen Verbindungsobjekt verwendet wurde, kann das Verbindungsobjekt dieses Transportobjekt verwenden.
public int heavyWeightReusedObjectCount()
Ruft die Anzahl der Objekte ab, die aus dem Pool wiederverwendet wurden.
public int createdObjectCount()
Ruft die Anzahl der seit der Poolerstellung vom DB2 Universal JDBC-Treiber erstellten Objekte ab.
public int agedOutObjectCount()
Ruft die Anzahl der Objekte ab, die die im Konfigurationsmerkmal db2.jcc.maxTransportObjectIdleTime angegebene Leerlaufzeit überschritten haben und aus dem Pool gelöscht wurden.
public int removedObjectCount()
Ruft die Anzahl der Objekte ab, die seit der Poolerstellung aus dem Pool gelöscht wurden.
public int totalPoolObjects()
Anzahl der Objekte, die sich momentan im Pool befinden.
Das Schlüsselwort OleDbReportIsLongForLongTypes wird für die folgenden Datenbankserver unterstützt:
CCE (Client Cursor Engine) von OLE DB und CommandBuilder von OLE DB .NET Data Provider generieren Aktualisierungs- und Löschanweisungen auf der Basis von Spalteninformationen, die von IBM DB2 OLE DB Provider bereitgestellt werden. Wenn die generierte Anweisung in der WHERE-Klausel einen LONG-Typ enthält, schlägt die Anweisung fehl, da LONG-Typen bei einer Suche mit Gleichheitsoperator nicht verwendet werden können. Wenn Sie das Schlüsselwort OleDbReportIsLongForLongTypes auf 1 setzen, meldet IBM DB2 OLE DB Provider LONG-Typen (LONG VARCHAR, LONG VARCHAR FOR BIT DATA, LONG VARGRAPHIC und LONG VARGRAPHIC FOR BIT DATA) über das gesetzte Flag DBCOLUMNFLAGS_ISLONG zurück. Dadurch wird verhindert, dass die Spalten mit LONG-Typen in der WHERE-Klausel verwendet werden.
Das Schlüsselwort OleDbSQLColumnsSortByOrdinal wird von den folgenden Datenbankservern unterstützt:
Die Microsoft OLE DB-Spezifikation erfordert, dass IDBSchemaRowset::GetRowset(DBSCHEMA_COLUMNS) die Zeilengruppe nach den Spalten TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME und COLUMN_NAME sortiert zurückgibt. IBM DB2 OLE DB Provider entspricht der Spezifikation. Allerdings wurden Anwendungen, die den Microsoft ODBC Bridge-Provider (MSDASQL) verwenden, normalerweise so codiert, dass die Zeilengruppe nach ORDINAL_POSITION sortiert wird. Wenn Sie das Schlüsselwort OleDbSQLColumnsSortByOrdinal auf 1 setzen, gibt der Provider eine Zeilengruppe zurück, die nach ORDINAL_POSITION sortiert ist.
IBM DB2 OLE DB Provider hat eine neue Eigenschaftsgruppe hinzugefügt: DB2 Data Source. Diese Eigenschaftsgruppe für DB2 Data Source ist DBPROPSET_DB2DATASOURCE.
Die GUID für die Eigenschaftsgruppe lautet wie folgt: {0x8a80412a,0x7d94,0x4fec,{0x87,0x3e,0x6c,0xd1,0xcd,0x42,0x0d,0xcd}}
DBPROPSET_DB2DATASOURCE weist drei Merkmale auf:
#define DB2PROP_REPORTISLONGFORLONGTYPES 4 Eigenschaftsgruppe: DB2 Data Source Eigenschaftsset: DB2PROPSET_DATASOURCE Typ: VT_BOOL Typischer Schreib-/Lesezugriff: R/W Beschreibung: IsLong für LONG-Typen zurückmelden
CCE (Client Cursor Engine) von OLE DB und CommandBuilder von OLE DB .NET Data Provider generieren Aktualisierungs- und Löschanweisungen auf der Basis von Spalteninformationen, die von IBM DB2 OLE DB Provider bereitgestellt werden. Wenn die generierte Anweisung in der WHERE-Klausel einen LONG-Typ enthält, schlägt die Anweisung fehl, da LONG-Typen bei einer Suche mit Gleichheitsoperator nicht verwendet werden können.
Werte | Bedeutung |
---|---|
VARIANT_TRUE | IBM DB2 OLE DB Provider meldet LONG-Typen (LONG VARCHAR, LONG VARCHAR FOR BIT DATA, LONG VARGRAPHIC und LONG VARGRAPHIC FOR BIT DATA) über das gesetzte Flag DBCOLUMNFLAGS_ISLONG zurück. Dadurch wird verhindert, dass die Spalten mit LONG-Typen in der WHERE-Klausel verwendet werden. |
VARIANT_FALSE | DBCOLUMNFLAGS_ISLONG ist für LONG VARCHAR, LONG VARCHAR FOR BIT DATA, LONG VARGRAPHIC und LONG VARGRAPHIC FOR BIT DATA nicht gesetzt. Dies ist der Standardwert. |
#define DB2PROP_RETURNCHARASWCHAR 2 Eigenschaftsgruppe: DB2 Data Source Eigenschaftsset: DB2PROPSET_DATASOURCE Typ: VT_BOOL Typischer Schreib-/Lesezugriff: R/W Beschreibung: Char als WChar zurückgeben
Werte | Bedeutung |
---|---|
VARIANT_TRUE | OLE DB beschreibt Spalten des Typs CHAR, VARCHAR, LONG VARCHAR oder CLOB als DBTYPE_WSTR. Die Codepage der in ISequentialStream implizierten Daten ist UCS-2. Dies ist der Standardwert. |
VARIANT_FALSE | OLE DB beschreibt Spalten des Typs CHAR, VARCHAR, LONG VARCHAR oder CLOB als DBTYPE_STR. Die Codepage der in ISequentialStream implizierten Daten ist die lokale Codepage des Clients. |
#define DB2PROP_SORTBYORDINAL 3 Eigenschaftsgruppe: DB2 Data Source Eigenschaftsset: DB2PROPSET_DATASOURCE Typ: VT_BOOL Typischer Schreib-/Lesezugriff: R/W Beschreibung: Nach Ordinalzahl sortieren
Die Microsoft OLE DB-Spezifikation erfordert, dass IDBSchemaRowset::GetRowset(DBSCHEMA_COLUMNS) die Zeilengruppe nach den Spalten TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME und COLUMN_NAME sortiert zurückgibt. IBM DB2 OLE DB Provider entspricht der Spezifikation. Allerdings wurden Anwendungen, die den Microsoft ODBC Bridge-Provider (MSDASQL) verwenden, normalerweise so codiert, dass die Zeilengruppe nach ORDINAL_POSITION sortiert wird.
Werte | Bedeutung |
---|---|
VARIANT_TRUE | Der Provider gibt eine Zeilengruppe zurück, die nach ORDINAL_POSITION sortiert ist. |
VARIANT_FALSE | Der Provider gibt eine Zeilengruppe zurück, die nach TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME und COLUMN_NAME sortiert ist. Dies ist der Standardwert. |
Im Thema "Installieren des allgemeinen DB2-Treibers", ist im Syntaxdiagramm für DB2Binder die URL-Syntax für den allgemeinen DB2-JDBC-Treiber falsch definiert. Die richtige Darstellung der URL-Syntax für DB2Binder sehen Sie im folgenden Diagramm:
Die Funktion für automatische Clientweiterleitung in DB2 Universal Database (UDB) für Linux, UNIX und Windows ermöglicht die Wiederherstellung von Clientanwendungen, nachdem die Verbindung zum Server unterbrochen wurde, so dass die Anwendungen nach minimaler Ausfallzeit weiterarbeiten können.
Immer wenn ein Server gesperrt wird, empfängt jeder Client, der mit diesem Server verbunden ist, einen Kommunikationsfehler, der die Verbindung beendet und zu einem Anwendungsfehler führt. Wenn die Verfügbarkeit wichtig ist, sollte eine redundante Installation oder eine Funktionsübernahme eingerichtet sein. (Die Funktionsübernahme ist die Fähigkeit des Servers, bei einem Ausfall eines anderen Servers dessen Aufgaben zu übernehmen.) In jedem Fall versucht der Client mit dem DB2 Universal JDBC-Treiber, die Verbindung zu einem neuen Server oder zum ursprünglichen Server wiederherzustellen, der möglicherweise auf einem Knoten mit Funktionsübernahme aktiv ist. Wenn die Verbindung wiederhergestellt wird, empfängt die Anwendung eine SQL-Ausnahmebedingung, die ihr das Fehlschlagen der Transaktion mitteilt, die Anwendung kann jedoch mit der nächsten Transaktion fortfahren.
Nachdem der Datenbankadministrator den alternativen Serverstandort für eine bestimmte Datenbank im Serverexemplar angegeben hat, werden die Positionen des primären und des alternativen Servers beim Verbindungsaufbau an den Client zurückgegeben. Der DB2 Universal JDBC-Treiber erstellt ein Exemplar des referenzierbaren Objekts DB2ClientRerouteServerList und speichert dieses in seinem Übergangsspeicher. Bei einem Kommunikationsausfall versucht der DB2 Universal JDBC-Treiber, die Verbindung unter Verwendung der vom Server zurückgegebenen Serverinformationen wieder herzustellen.
Das DataSource-Merkmal clientRerouteServerListJNDIName stellt auf dem Client zusätzliche Unterstützung für die Clientweiterleitung zur Verfügung; clientRerouteServerListJNDIName hat die folgenden zwei Funktionen:
clientRerouteServerListJNDIName gibt eine JNDI-Referenz zu einem DB2ClientRerouteServerList-Exemplar in einem JNDI-Repository für Daten zu alternativen Server an. Nach erfolgreicher Herstellung der Verbindung zum primären Server werden die Daten zum alternativen Server, die von clientRerouteServerListJNDIName zur Verfügung gestellt werden, mit den Daten vom Server überschrieben. Der DB2 Universal JDBC-Treiber versucht, die aktualisierten Daten nach der Funktionsübernahme an den JNDI-Speicher weiterzugeben, falls das Merkmal clientRerouteServerListJNDIName definiert ist. Wenn clientRerouteServerListJNDIName angegeben ist, werden für die Verbindung zum primären Server Informationen verwendet, die in DB2ClientRerouteServerList angegeben sind. Wenn der primäre Server nicht angegeben ist, werden die serverName-Informationen verwendet, die auf der Datenquelle angegeben sind.
DB2ClientRerouteServerList ist eine serialisierbare JavaBean mit den folgenden vier Merkmalen:
Getter- und Setter-Methoden zum Zugriff auf diese Merkmale werden zur Verfügung gestellt. Die Definition der Klasse DB2ClientRerouteServerList lautet wie folgt:
package com.ibm.db2.jcc; public class DB2ClientRerouteServerList implements java.io.Serializable, javax.naming.Referenceable { public String[] alternateServerName; public synchronized void setAlternateServerName(String[] alternateServer); public String[] getAlternateServerName(); public int[] alternatePortNumber; public synchronized void setAlternatePortNumber(int[] alternatePortNumberList); public int[] getAlternatePortNumber(); public synchronized void setPrimaryServerName (String primaryServerName); public String getPrimaryServerName (); public synchronized void setPrimaryPortNumber (int primaryPortNumber) public int getPrimaryPortNumber (); }
Eine neue hergestellte Verbindung für Funktionsübernahme wird mit den ursprünglichen Datenquellenmerkmalen konfiguriert, mit Ausnahme des Servernamens und der Portnummer. Außerdem werden alle DB2 UDB-Sonderregister, die bei der ursprünglichen Verbindung modifiziert worden sind, in der Funktionsübernahmeverbindung vom DB2 Universal JDBC-Treiber wiederhergestellt.
Bei einem Kommunikationsausfall versucht der DB2 Universal JDBC-Treiber zuerst eine Wiederherstellung für den primären Server auszuführen. Sollte dies fehlschlagen, versucht der Treiber, eine Verbindung zur alternativen Position (Funktionsübernahme) herzustellen. Nachdem erneut eine Verbindung hergestellt worden ist, sendet der Treiber eine java.sql.SQLException mit dem SQLCODE-Wert -4498 an die Anwendung, wodurch der Anwendung angezeigt wird, dass automatisch eine Verbindung zum alternativen Server wiederhergestellt worden ist. Die Anwendung kann anschließend die Transaktion wiederholen.
Gehen Sie wie folgt vor, um Speicher so zu konfigurieren, dass DB2ClientRerouteServerList persistent festgelegt wird:
// Startkontext für Namensoperationen erstellen InitialContext registry = new InitialContext(); // DB2ClientRerouteServerList-Objekt erstellen DB2ClientRerouteServerList address=new DB2ClientRerouteServerList(); // Portnummer und Servernamen für primären Server setzen address.setPrimaryPortNumber(50000); address.setPrimaryServerName("mvs1.sj.ibm.com"); // Portnummer und Servernamen für alternativen Server setzen int[] port = {50002}; String[] server = {"mvs3.sj.ibm.com"}; address.setAlternatePortNumber(port); address.setAlternateServerName(server); registry.rebind("serverList", address);
datasource.setClientRerouteServerListJNDIName("serverList");
Über die Merkmale der DB2 Universal JDBC-Treiberkonfiguration können Sie Merkmalwerte setzen, die für den gesamten Treiber gelten. Diese Einstellungen werden anwendungsübergreifend und DataSource-Exemplar-übergreifend angewendet. Sie können die Einstellungen ändern, ohne den Anwendungsquellcode oder die DataSource-Merkmale zu ändern.
Die einzelnen Merkmaleinstellungen der DB2 Universal JDBC-Treiberkonfiguration weisen das folgende Format auf:
merkmal=wert
Wenn das Konfigurationsmerkmal mit db2.jcc.override beginnt, ist es auf alle Verbindungen anwendbar und überschreibt alle Connection- oder DataSource-Merkmale mit demselben Merkmalnamen. Wenn das Konfigurationsmerkmal mit db2.jcc oder db2.jcc.default beginnt, ist der Konfigurationsmerkmalwert ein Standardwert. Einstellungen für die Connection- oder DataSource-Merkmale überschreiben diesen Wert.
Gehen Sie wie folgt vor, um Konfigurationsmerkmale festzulegen:
Für Standalone-Java-Anwendungen können Sie die Konfigurationsmerkmale als Java-Systemmerkmale festlegen, indem Sie bei der Ausführung des Befehls java die Option -Dmerkmal=wert angeben.
Für Standalone-Java-Anwendungen können Sie die Konfigurationsmerkmale festlegen, indem Sie bei der Ausführung des Befehls java die Option -Ddb2.jcc.propertiesFile=pfad angeben.
DB2JccConfiguration.properties kann eine Standalone-Datei sein oder sich in einer JAR-Datei befinden.
Wenn DB2JccConfiguration.properties eine Standalone-Datei ist, muss der Pfad für DB2JccConfiguration.properties in der CLASSPATH-Angabe enthalten sein.
Wenn DB2JccConfiguration.properties sich in einer JAR-Datei befindet, muss diese JAR-Datei in der CLASSPATH-Angabe enthalten sein.
Sie können die folgenden Konfigurationsmerkmale für DB2 Universal JDBC-Treiber festlegen. Alle Merkmale sind optional.
Geben Sie einen vollständig qualifizierten Dateinamen als Wert des Merkmals db2.jcc.override.traceFile an.
Das Merkmal db2.jcc.override.traceFile überschreibt das Merkmal traceFile für ein Connection- oder DataSource-Objekt.
Wenn Sie z. B. die folgende Einstellung für db2.jcc.override.traceFile angeben, wird die Traceverarbeitung des Java-Codes für den DB2 Universal JDBC-Treiber in einer Datei mit dem Namen /SYSTEM/tmp/jdbctrace aufgezeichnet:
db2.jcc.override.traceFile=/SYSTEM/tmp/jdbctrace
Sie sollten die Tracemerkmale unter Anleitung der IBM Unterstützungsfunktion festlegen.
Die Funktion db2secFreeToken (durch Token belegten Speicher freigeben) ist nicht mehr Bestandteil der Benutzerauthentifizierungs-Plug-in-API db2secGssapiServerAuthFunctions_1.
Die Integrität der Installation von DB2 Universal Database (UDB) kann beeinträchtigt sein, wenn die Implementierung von Sicherheits-Plug-ins nicht auf geeignete Weise codiert, geprüft und getestet wird. DB2 UDB ergreift Vorsichtsmaßnahmen gegen viele allgemein auftretende Arten von Fehlern, kann jedoch keine vollständige Integrität garantieren, wenn benutzerdefinierte Sicherheits-Plug-ins implementiert werden.
Wenn Sie Ihr eigenes Sicherheits-Plug-in verwenden, können Sie in einer CONNECT-Anweisung, die über den Befehlszeilenprozessor (CLP) oder über eine Anweisung für dynamisches SQL abgesetzt wird, eine Benutzer-ID mit bis zu 255 Zeichen verwenden.
Für die APIs db2secGetGroupsForUser, db2secValidatePassword und db2secGetAuthIDs kann der Eingabeparameter dbname einen Nullwert haben, und der entsprechende Eingabeparameter dbnamelen für die Länge wird auf 0 gesetzt.
.so wird nun als Dateinamenerweiterung für benutzerdefinierte Sicherheits-Plug-in-Bibliotheken auf allen Linux- und UNIX-Plattformen akzeptiert.
Unter AIX können Sicherheits-Plug-in-Bibliotheken die Erweiterung .a oder .so aufweisen. Sollten beide Versionen der Plug-in-Bibliothek vorhanden sein, wird die Version mit der Erweiterung .a verwendet.
Unter HP-UX auf PA-RISC können Sicherheits-Plug-in-Bibliotheken die Erweiterung .sl oder .so aufweisen. Sollten beide Versionen der Plug-in-Bibliothek vorhanden sein, wird die Version mit der Erweiterung .sl verwendet.
Auf allen übrigen Linux- und UNIX-Plattformen ist .so die einzige unterstützte Dateinamenerweiterung für Sicherheits-Plug-in-Bibliotheken.
Unter AIX können Sicherheits-Plug-in-Bibliotheken die Dateinamenerweiterung .a oder .so aufweisen. Der Mechanismus zum Laden der Plug-in-Bibliothek hängt von der verwendeten Erweiterung ab:
Beispiel für die Erzeugung einer Plug-in-Bibliothek als 32-Bit-Archiv:
xlc_r -qmkshrobj -o shr.o MeinPlugin.c -bE:MeinPlugin.exp ar rv MeinPlugin.a shr.o
xlc_r -qmkshrobj -o MeinPlugin.so MeinPlugin.c -bE:MeinPlugin.exp
Auf allen Plattformen außer AIX wird angenommen, dass Sicherheits-Plug-in-Bibliotheken immer dynamisch ladbare gemeinsam genutzte Objekte sind.
| | |In DB2 UDB Version 8.2 für Linux, UNIX und Windows können Sie Ihre eigenen |Authentifizierungsverfahren in Form von Plug-ins (ladbare Bibliotheken) erstellen. Die DB2 UDB-Steuerkomponente lädt diese Plug-ins und greift auf sie zu, um Benutzer zu authentifizieren. Der DB2 Universal JDBC-Treiber stellt Sicherheits-Plug-in-Unterstützung in DB2 UDB |Version 8.2 FixPak 4 bereit, um in Java geschriebene benutzerdefinierte Anwendungen zu unterstützen.
|Bei Java-Anwendungen, die mit dem DB2 Universal JDBC-Treiber Plug-in-Authentifizierung ausführen, müssen Benutzer ihr eigenes Plug-in implementieren, indem sie die abstrakte Klasse com.ibm.db2.jcc.DB2JCCPlugin erweitern und die folgenden Merkmale festlegen:
|Beispiel:
|java.util.Properties properties = new java.util.Properties(); | properties.put("user", "db2admin"); | properties.put("password", "admindb2"); | properties.put("pluginName", "gssapi_simple"); | properties.put("securityMechanism", | new String(""+com.ibm.db2.jcc.DB2BaseDataSource.PLUGIN_SECURITY+"")); | properties.put("plugin", new JCCSimpleGSSPlugin()); | Connection con = java.sql.DriverManager.getConnection(url, properties);
Bei der GSS-API-Authentifizierung wird nur ein einziges Token vom Client an den Server und ein einziges Token vom Server an den Client gesendet. Diese Tokens werden auf dem Client von gss_init_sec_context() und auf dem Server von gss_accept_sec_context() abgerufen. Wenn GSS-API-Plug-ins versuchen, weitere Tokens zu senden, wird ein unerwarteter Fehler für Sicherheits-Plug-ins generiert, und die Verbindung schlägt fehl.
Nachrichtenverschlüsselung und Signaturen sind in GSS-API-Sicherheits-Plug-ins nicht verfügbar.
Alle (normalen und abnormalen) Beendigungen machen, unabhängig vom Betriebssystem, ausstehende Arbeitseinheiten implizit rückgängig.
Die Dokumentation zu neuen Funktionen für DB2 Universal Database (UDB) Version 8.2 enthält im Abschnitt zu den DB2 Universal JDBC-Treiberverbesserungen falsche Informationen zur Unterstützung von verteilten Transaktionen. Der letzte Satz dieses Abschnitts ist falsch. Richtig muss er wie folgt lauten:
Ab Version 8.2 stellt DB2 UDB Unterstützung für verteilte Transaktionsverarbeitung bereit, die der XA-Spezifikation entspricht. Diese Unterstützung implementiert die JTS- (Java Transaction Service) und JTA-Spezifikationen (Java Transaction API) von Java 2 Platform Enterprise Edition (J2EE).
[ Seitenanfang |Vorherige Seite | Nächste Seite | Inhaltsverzeichnis ]