Anwendungsentwicklung: Programmieren von Clientanwendungen

| | |

Lastausgleich für DB2 Universal JDBC-Treiber über Verbindungskonzentrator und Sysplex

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-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:

Verwendung von Traces, die Sie unter Verwendung der Konfigurationsmerkmale des DB2 Universal JDBC-Treibers starten

Verwendung einer Anwendungsprogrammierschnittstelle

| |

Konfigurationsmerkmale des DB2 Universal JDBC-Treibers für den Verbindungskonzentrator- und Sysplex-Lastausgleich

Jedes der folgenden Konfigurationsmerkmale wird für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet.

db2.jcc.dumpPool

|||Gibt zusätzlich zur geschriebenen Zusammenfassungsstatistik die Statistiktypen an, die für globale Transportpoolereignisse geschrieben wurden. Der globale Transportpool wird für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet. | |

Der Datentyp von db2.jcc.dumpPool ist eine ganze Zahl (int.). Die Konfigu- |rationsmerkmale db2.jcc.dumpPoolStatisticsOnSchedule |und db2.jcc.dump- |PoolStatisticsOnScheduleFile müssen für das Schreiben von Statistiken eben- |falls festgelegt werden, noch bevor Statistiken geschrieben werden.

Sie können für das Merkmal db2.jcc.dumpPool folgende Statistiktypen angeben:

DUMP_REMOVE_OBJECT (hexadezimal: X'01', dezimal: 1)

DUMP_GET_OBJECT (hexadezimal: X'02', dezimal: 2)

DUMP_WAIT_OBJECT (hexadezimal: X'04', dezimal: 4)

DUMP_SET_AVAILABLE_OBJECT (hexadezimal: X'08', dezimal: |8)

DUMP_CREATE_OBJECT (hexadezimal: X'10', dezimal: 16)

DUMP_SYSPLEX_MSG (hexadezimal: X'20', dezimal: 32)

DUMP_POOL_ERROR (hexadezimal: X'80', dezimal: 128)

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.

db2.jcc.dumpPoolStatisticsOnSchedule

||||Gibt in der Maßeinheit Sekunden an, wie oft Transportpoolstatistiken in die Datei geschrieben werden, die mit dem Konfigurationsmerkmal db2.jcc.dumpPoolStatisticsOnScheduleFile angegeben wurde. Der globale Transportpool wird für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet. |

Der Standardwert lautet -1, d. h., die Statistikdaten für den globalen Transportpool werden nicht überschrieben.

db2.jcc.dumpPoolStatisticsOnScheduleFile

||||Gibt den Namen der Datei an, in die die Statistikdaten für den globalen Transportpool geschrieben werden. Der globale Transportpool wird für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet. |

Wenn das Konfigurationsmerkmal db2.jcc.dumpPoolStatisticsOnScheduleFile nicht angegeben ist, werden die Statistikdaten für den globalen Transportpool nicht geschrieben.

db2.jcc.maxTransportObjectIdleTime

||||Gibt die Zeitspanne in Sekunden an, die ein nicht verwendetes Transportobjekt im globalen Transportobjektpool bleibt, bis es aus dem Pool gelöscht werden kann. Transportobjekte werden für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet. |

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.

db2.jcc.maxTransportObjectWaitTime

||||Gibt die Höchstdauer in Sekunden an, die eine Anwendung auf ein Transportobjekt wartet, falls der Wert für db2.jcc.maxTransportObjects erreicht wurde. Transportobjekte werden für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet. Wenn eine Anwendung länger wartet als im Wert für db2.jcc.maxTransportObjectWaitTime angegeben, löst der globale Transportobjektpool eine SQLException aus. |

Der Standardwert für das Konfigurationsmerkmal db2.jcc.maxTransportObjectWaitTime beträgt -1. Ein negativer Wert bedeutet, dass Anwendungen unbegrenzte Zeit warten.

db2.jcc.maxTransportObjects

||||Gibt die Obergrenze für die Anzahl Transportobjekte in einem globalen Transportobjektpool für den Verbindungskonzentrator- und Sysplex-Last- |ausgleich an. Wenn die Anzahl Transportobjekte im Pool den Wert für db2.jcc.maxTransportObjects erreicht, werden Transportobjekte aus dem Pool gelöscht, die nicht länger als im Wert für db2.jcc.maxTransportObjectIdleTime angegeben verwendet wurden. |

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.

db2.jcc.minTransportObjects

||||Gibt die Untergrenze für die Anzahl Transportobjekte in einem globalen Transportobjektpool für den Verbindungskonzentrator- und Sysplex-Lastausgleich an. Wenn eine JVM erstellt wird, sind im Pool keine Transportobjekte vorhanden. |Transportobjekte werden dem Pool bei Bedarf hinzugefügt. Nach Erreichen des Werts für db2.jcc.minTransportObjects unterschreitet die Anzahl Transportobjekte im globalen Transportobjektpool für die Lebensdauer der entsprechenden JVM nie den Wert für db2.jcc.minTransportObjects. |

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.

|| | |

DataSource-Merkmale für den DB2 Universal JDBC-Treiber zum Verbindungskonzentrator- und Sysplex-Lastausgleich

Jedes der folgenden DataSource-Merkmale für den DB2 Universal JDBC-Treiber wird für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet.

enableConnectionConcentrator

|||Gibt an, ob die Verbindungskonzentratorfunktion des DB2 Universal JDBC-Treibers aktiviert ist. Die Verbindungskonzentratorfunktion ist nur für Verbindungen zu DB2 UDB für z/OS-Server verfügbar. |

Der Datentyp des Merkmals enableConnectionConcentrator ist Boolean. Der Standardwert ist false. Wenn jedoch enableSysplexWLB auf true gesetzt ist, lautet der Standardwert true.

enableSysplexWLB

||||Gibt an, ob die Sysplex-Lastausgleichsfunktion des DB2 Universal JDBC-Treibers aktiviert ist. Die Sysplex-Lastausgleichsfunktion ist nur für Verbindungen zu DB2 UDB für z/OS-Servern verfügbar. |

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.

maxTransportObjects

||||Gibt die maximale Anzahl Transportobjekte an, die für alle Verbindungen mit dem zugeordneten DataSource-Objekt verwendet werden können. Transportobjekte werden für den Verbindungskonzentrator- und Sysplex-Lastausgleich verwendet. Der Wert für maxTransportObjects wird ignoriert, falls das Merkmal enableConnectionConcentrator oder enableSysplexWLB nicht so eingestellt ist, dass die Verwendung des Verbindungskonzentrator- und Sysplex-Lastausgleichs aktiviert ist. |

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.

|| | |

Beispiel für die Aktivierung der Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion für den DB2 Universal JDBC-Treiber bei WebSphere Application Server

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.

|Voraussetzungen |

Servervoraussetzungen:

WLM für z/OS

DB2 UDB für OS/390^(R) und z/OS ab Version 7

Clientvoraussetzungen:

DB2 Universal JDBC-Treiber mit FixPak 10

WebSphere Application Server ab Version 5.1

|Vorgehensweise |

Gehen Sie wie folgt vor, um die Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion für den DB2 Universal JDBC-Treiber bei WebSphere Application Server zu aktivieren:

Überprüfen Sie, ob der DB2 Universal JDBC-Treiber die richtige Stufe aufweist, damit er die Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion unterstützt. Setzen Sie dazu an den Befehlszeilenprozessor unter z/OS oder in den System Services unter UNIX den folgenden Befehl ab: |
```
java com.ibm.db2.jcc.DB2Jcc -version
```
Suchen Sie in der Ausgabe eine Zeile ähnlich der Folgenden: |
```
[ibm][db2][jcc] Driver: IBM DB2 JDBC Universal Driver Architecture n n
```
Dabei steht n für eine Versionsnummer ab 2.7.

Setzen Sie die Konfigurationsmerkmale für den DB2 Universal JDBC-Treiber so, dass der Verbindungskonzentrator- und Sysplex-Lastausgleich für alle DataSource-Exemplare aktiviert wird, die unter dem Treiber erstellt werden. |
Legen Sie die Konfigurationsmerkmale in der Datei DB2JccConfiguration.properties fest.
|
1. Erstellen Sie eine Datei mit dem Namen DB2JccConfiguration.properties, oder editieren Sie die vorhandene Datei DB2JccConfiguration.properties.
2. Legen Sie die folgenden Konfigurationsmerkmale fest: |
  - db2.jcc.minTransportObjects
  - db2.jcc.maxTransportObjects
  - db2.jcc.maxTransportObjectWaitTime
  - db2.jcc.dumpPool
  - db2.jcc.dumpPoolStatisticsOnScheduleFile
  Starten Sie mit Einstellungen ähnlich den Folgenden: |
```
db2.jcc.minTransportObjects=0
|db2.jcc.maxTransportObjects=1500
|db2.jcc.maxTransportObjectWaitTime=-1
|db2.jcc.dumpPool=0
|db2.jcc.dumpPoolStatisticsOnScheduleFile=
|  /home/WAS/logs/srv1/poolstats
```
3. Fügen Sie den Verzeichnispfad für die Datei DB2JccConfiguration.properties dem Klassenpfad des DB2 Universal JDBC-Treibers für WebSphere Application Server hinzu.

Legen Sie die Datenquellenmerkmale für den DB2 Universal JDBC-Treiber so fest, dass die Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion aktiviert ist. |

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:

enableSysplexWLB

enableConnectionConcentrator

maxTransportObjects

Angenommen, Sie möchten sowohl die Verbindungskonzentratorfunktion als auch die Sysplex-Lastausgleichsfunktion aktivieren. Starten Sie mit Einstellungen ähnlich den Folgenden: | ||||||||||||||||||||||

Tabelle 26. Beispiel für Einstellungen von Datenquellenmerkmalen für die Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion für den DB2 Universal JDBC-Treiber
Merkmal	Einstellung
enableSysplexWLB	true¹
maxTransportObjects	100
\| \| Anmerkungen: \| \| Das Merkmal enableConnectionConcentrator ist standardmäßig auf `true` gesetzt, da das Merkmal enableSysplexWLB auf `true` gesetzt ist. \|

Starten Sie WebSphere Application Server erneut.

| |

Methoden zur Überwachung der Verbindungskonzentrator- und Sysplex-Lastausgleichsfunktion für den DB2 Universal JDBC-Treiber

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:

Verwendung von Traces, die Sie über die Einstellung der Konfigurationsmerkmale des DB2 Universal JDBC-Treibers starten

Verwendung einer Anwendungsprogrammierschnittstelle

| |

Konfigurationsmerkmale zur Überwachung des globalen Transportobjektpools

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:

npr: Gesamtzahl der Anforderungen, die der DB2 Universal JDBC-Treiber seit der Erstellung des Pools an diesen gesendet hat. |
nsr: Anzahl der erfolgreichen Anforderungen, die der DB2 Universal JDBC-Treiber an den Pool seit der Erstellung des Pools gesendet hat. Eine erfolgreiche Anforderung bedeutet, dass der Pool ein Objekt zurückgegeben hat. |
lwroc: Anzahl der Objekte, 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. |
hwroc: Anzahl der Objekte, die aus dem Pool wiederverwendet wurden. |
coc: Anzahl der seit der Poolerstellung vom DB2 Universal JDBC-Treiber erstellten Objekte. |
aooc: Anzahl der Objekte, die die im Konfigurationsmerkmal db2.jcc.maxTransportObjectIdleTime angegebene Leerlaufzeit überschritten haben und aus dem Pool gelöscht wurden. |
rmoc: Anzahl der Objekte, die seit der Poolerstellung aus dem Pool gelöscht wurden. |
nbr: Anzahl der Anforderungen, 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 Konfigura- |tionswert für db2.jcc.maxTransportObjectWaitTime überschritten und eine Ausnahmebedingung ausgelöst wird. |
tbt: Gesamtzeit in Millisekunden, 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. |
tpo: Anzahl der Objekte, die sich momentan im Pool befinden. |

| |

Anwendungsprogrammierschnittstellen zur Überwachung des globalen Transportobjektpools

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.

getMonitorVersion

||Format: |

public int getMonitorVersion()

Ruft die Version der DB2PoolMonitor-Klasse ab, die mit dem DB2 Universal JDBC-Treiber ausgeliefert wird.

totalRequestsToPool

||Format: |

public int totalRequestsToPool()

Ruft die Gesamtzahl der Anforderungen ab, die der DB2 Universal JDBC-Treiber seit der Poolerstellung an den Pool gesendet hat.

successfullRequestsFromPool

||Format: |

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.

numberOfRequestsBlocked

||Format: |

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.

totalTimeBlocked

||Format: |

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.

lightWeightReusedObjectCount

||Format: |

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.

heavyWeightReusedObjectCount

||Format: |

public int heavyWeightReusedObjectCount()

Ruft die Anzahl der Objekte ab, die aus dem Pool wiederverwendet wurden.

createdObjectCount

||Format: |

public int createdObjectCount()

Ruft die Anzahl der seit der Poolerstellung vom DB2 Universal JDBC-Treiber erstellten Objekte ab.

agedOutObjectCount

||Format: |

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.

removedObjectCount

||Format: |

public int removedObjectCount()

Ruft die Anzahl der Objekte ab, die seit der Poolerstellung aus dem Pool gelöscht wurden.

totalPoolObjects

||Format: |

public int totalPoolObjects()

Anzahl der Objekte, die sich momentan im Pool befinden.

CLI/ODBC-Konfigurationsschlüsselwort OleDbReportIsLongForLongTypes

Das Schlüsselwort OleDbReportIsLongForLongTypes wird für die folgenden Datenbankserver unterstützt:

DB2 UDB für z/OS Version 6 mit PTF UQ93891
DB2 UDB für z/OS Version 7 mit PTF UQ93889
DB2 UDB für z/OS Version 8 mit PTF UQ93890
DB2 UDB für Linux, UNIX und Windows ab Version 8.2 (äquivalent zu Version 8.1 FixPak 7)

Beschreibung des Schlüsselworts: Bewirkt, dass OLE DB LONG-Datentypen mit DBCOLUMNFLAGS_ ISLONG markiert.
Syntax für das Schlüsselwort der db2cli.ini:: OleDbReportIsLongForLongTypes = 0 | 1
Funktional entsprechendes Anweisungsattribut:: SQL_ATTR_REPORT_ISLONG_FOR_LONGTYPES_OLEDB
Standardeinstellung:: Für LONG-Typen (LONG VARCHAR, LONG VARCHAR FOR BIT DATA, LONG VARGRAPHIC und LONG VARGRAPHIC FOR BIT DATA) ist das Flag DBCOLUMNFLAGS_ISLONG nicht gesetzt. Dadurch können die Spalten ggf. in der WHERE-Klausel verwendet werden.
Verwendungshinweise:

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.

CLI/ODBC-Konfigurationsschlüsselwort OleDbSQLColumnsSortByOrdinal

Das Schlüsselwort OleDbSQLColumnsSortByOrdinal wird von den folgenden Datenbankservern unterstützt:

DB2 UDB für z/OS Version 6 mit PTF UQ93891
DB2 UDB für z/OS Version 7 mit PTF UQ93889
DB2 UDB für z/OS Version 8 mit PTF UQ93890
DB2 UDB für Linux, UNIX und Windows ab Version 8.2 (äquivalent zu Version 8.1 FixPak 7)

Beschreibung des Schlüsselworts: Bewirkt, dass IDBSchemaRowset::GetRowset(DBSCHEMA_COLUMNS) von OLE DB eine Zeilengruppe zurückgibt, die nach der Spalte ORDINAL_POSITION sortiert ist.
Syntax für das Schlüsselwort der db2cli.ini:: OleDbSQLColumnsSortByOrdinal = 0 | 1
Funktional entsprechendes Anweisungsattribut:: SQL_ATTR_SQLCOLUMNS_SORT_BY_ORDINAL_OLEDB
Standardeinstellung:: IDBSchemaRowset::GetRowset(DBSCHEMA_COLUMNS) gibt die Zeilengruppe nach den Spalten TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME und COLUMN_NAME sortiert zurück.
Verwendungshinweise:

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.

Eigenschaftsgruppe DB2 Data Source für IBM DB2 OLE DB Provider

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:

DB2PROP_REPORTISLONGFORLONGTYPES
DB2PROP_RETURNCHARASWCHAR
DB2PROP_SORTBYORDINAL

DB2PROP_REPORTISLONGFORLONGTYPES

#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

Tabelle 27. Werte für DB2PROP_REPORTISLONGFORLONGTYPES
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.

DB2PROP_RETURNCHARASWCHAR

#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

Tabelle 28. Werte für DB2PROP_RETURNCHARASWCHAR
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.

DB2PROP_SORTBYORDINAL

#define DB2PROP_SORTBYORDINAL 3
Eigenschaftsgruppe: DB2 Data Source 
Eigenschaftsset: DB2PROPSET_DATASOURCE
Typ: VT_BOOL
Typischer Schreib-/Lesezugriff: R/W
Beschreibung: Nach Ordinalzahl sortieren

Tabelle 29. Werte für DB2PROP_SORTBYORDINAL
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.

Falsche URL-Syntax im Syntaxdiagramm für DB2Binder

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:

Syntax für DB2Binder

>>-java--com.ibm.db2.jcc.DB2Binder------------------------------>
 
>---url jdbc:db2://server-+---------+-/datenbank---------------->
                          '-:--port-'
 
>---user benutzer-id---password kennwort------------------------>
 
>--+------------------+--+-------------------------------+------>
   '--size ganze-zahl-'  '--collection objektgruppenname-'
 
>--+-------------------------------+--+-------+----------------><
   |              .-,------------. |  '--help-'
   |              V              | |
   '--tracelevel ---trace-option-+-'

Datenweiterleitung bei Clients mit DB2 Universal JDBC-Treiber

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.

Einschränkungen

Die Unterstützung für die Clientweiterleitung mit dem DB2 Universal JDBC-Treiber ist nur für Verbindungen verfügbar, die die Schnittstelle javax.sql.DataSource verwenden.
Bevor eine Clientanwendung nach einem Kommunikationsausfall wiederhergestellt werden kann, muss auf dem Server die Position eines alternativen Servers angegeben werden. Der Datenbankadministrator gibt den alternativen Server mit dem Befehl UPDATE ALTERNATE SERVER FOR DATABASE an.

Vorgehensweise

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:

Daten zu alternativen Servern können JVM-übergreifend persistent vorhanden sein.
Falls die erste Verbindung zum Datenbankserver fehlschlägt, wird die Position eines alternative Servers zur Verfügung gestellt.

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 verwen- det, die auf der Datenquelle angegeben sind.

DB2ClientRerouteServerList ist eine serialisierbare JavaBean mit den folgenden vier Merkmalen:

alternateServerName
alternatePortNumber
primaryServerName
primaryPortNumber

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.

Vorgehensweise zum persistenten Festlegen von DB2ClientRerouteServerList

Gehen Sie wie folgt vor, um Speicher so zu konfigurieren, dass DB2ClientRerouteServerList persistent festgelegt wird:

Erstellen Sie ein Exemplar von DB2ClientRerouteServerList, und binden Sie dieses Exemplar an die JNDI-Registrierdatenbank. Beispiel:

// 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);

Ordnen Sie den JNDI-Namen des DB2ClientRerouteServerList-Objekts dem DataSource-Merkmal clientRerouteServerListJNDIName zu. Beispiel:
```
datasource.setClientRerouteServerListJNDIName("serverList");
```

Anpassen der Merkmale der DB2 Universal JDBC-Treiberkonfiguration

Ü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.

Vorgehensweise

Gehen Sie wie folgt vor, um Konfigurationsmerkmale festzulegen:

Definieren Sie die Konfigurationsmerkmale als Java-Systemmerkmale. Diese Einstellungen überschreiben alle anders lautenden Einstellungen.
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.
Legen Sie die Konfigurationsmerkmale in einer Ressource fest, deren Namen Sie im Java-Systemmerkmal db2.jcc.propertiesFile angeben. Sie können z. B. für den Wert db2.jcc.propertiesFile einen absoluten Pfadnamen 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.
Definieren Sie die Konfigurationsmerkmale in einer Ressource mit dem Namen DB2JccConfiguration.properties. Die Ressource DB2JccConfiguration.properties wird mit einer Standard-Java-Ressourcensuche gesucht. Der DB2 Universal JDBC-Treiber sucht nur nach dieser Ressource, wenn Sie das Java-Systemmerkmal db2.jcc.propertiesFile nicht gesetzt haben.
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.

db2.jcc.override.traceFile

Aktiviert den DB2 Universal JDBC-Treibertrace für Java-Treibercode, und gibt den Namen an, auf dem die Tracedateinamen basieren.

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.

db2.jcc.sqljUncustomizedWarningOrException

Gibt die Aktion an, die der DB2 Universal JDBC-Treiber ausführt, wenn eine nicht angepasste SQLJ-Anwendung aktiv ist. db2.jcc.sqljUncustomizedWarningOrException kann die folgenden Werte aufweisen:

0: Der DB2 Universal JDBC-Treiber generiert keine Warnung oder Ausnahmebedingung, wenn eine nicht angepasste SQLJ-Anwendung aktiv ist. Dies ist der Standardwert.
1: Der DB2 Universal JDBC-Treiber generiert eine Warnung, wenn eine nicht angepasste SQLJ-Anwendung aktiv ist.
2: Der DB2 Universal JDBC-Treiber generiert eine Ausnahmebedin- gung, wenn eine nicht angepasste SQLJ-Anwendung aktiv ist.

Funktion db2secFreeToken entfernt

Die Funktion db2secFreeToken (durch Token belegten Speicher freigeben) ist nicht mehr Bestandteil der Benutzerauthentifizierungs-Plug-in-API db2secGssapiServerAuthFunctions_1.

Sorgfältiges Implementieren benutzerdefinierter Sicherheits-Plug-ins

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.

Sicherheits-Plug-ins

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.

Sicherheits-Plug-in-APIs

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.

Namenskonventionen für Sicherheits-Plug-ins (Linux und UNIX)

.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.

Einschränkungen 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:

Plug-in/Bibliotheken mit der Dateinamenerweiterung .a

Plug-in/Bibliotheken mit der Dateinamenerweiterung .a gelten als Archive, die gemeinsam genutzte Objektelemente enthalten. Diese Elemente müssen den Namen shr.o (32 Bit) oder shr64.o (64 Bit) aufweisen. Ein einzelnes Archiv kann sowohl 32-Bit- als auch 64-Bit-Elemente enthalten, so dass es auf beiden Plattformtypen implementiert werden kann.

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

Plug-in/Bibliotheken mit der Dateinamenerweiterung .so

Plug-in-Bibliotheken mit der Dateinamenerweiterung .so gelten als dynamisch ladbare gemeinsam genutzte Objekte. Ein solches Objekt ist entweder ein 32-Bit- oder ein 64-Bit-Objekt, je nachdem, welche Optionen bei seiner Erzeugung zur Kompilierung und zum Binden verwendet wurden. Beispiel für die Erzeugung einer 32-Bit-Plug-in-Bibliothek:

  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.

GSS-API-Sicherheits-Plug-ins unterstützen keine Authentifizierung mit mehreren Tokens

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.

GSS-API-Sicherheits-Plug-ins unterstützen keine Nachrichtenverschlüsselung und keine Signaturen

Nachrichtenverschlüsselung und Signaturen sind in GSS-API-Sicherheits-Plug-ins nicht verfügbar.

Implizite Beendung von Transaktionen in Standalone-Anwendungen

Alle (normalen und abnormalen) Beendigungen machen, unabhängig vom Betriebssystem, ausstehende Arbeitseinheiten implizit rückgängig.

Unterstützung verteilter Transaktionen

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 Transaktionsverarbei- tung 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 ]