Podręcznik Application Development Guide: Programming Client Applications

| | |

Połączenie sterownika uniwersalnego JDBC DB2 typu 4 z programem DB2 for VM/VSE nie jest obsługiwane

Sterownik uniwersalny JDBC DB2 nie obsługuje połączenia typu 4 z bazami danych programu DB2 for VM/VSE. Tematy zatytułowane "Setting up the Windows Java environment" i "Installing the DB2 Universal JDBC Driver" w podręczniku Application Development Guide: Programming Client Applications, i w Centrum informacyjnym programu DB2 UDB zawierają nieprawidłowe informacje, że sterownik uniwersalny JDBC DB2 obsługuje połączenie typu 4 z bazami danych programu DB2 for VM/VSE.

Koncentrator połączeń sterownika uniwersalnego JDBC DB2 i równoważenie obciążeń sysplex

Aplikacje Java uzyskujące dostęp do serwerów DB2 UDB for z/OS^(R) za pomocą produktu DB2 Universal JDBC Type 4 Connectivity mogą skorzystać z jego funkcji koncentratora połączeń i równoważenia obciążeń sysplex.

Funkcje te są podobne do funkcji koncentratora połączeń i równoważenia obciążeń sysplex programu DB2 Connect.

Koncentrator połączeń sterownika uniwersalnego JDBC DB2 może zmniejszyć ilość zasobów, których serwery baz danych DB2 UDB for z/OS^(R) wymagają do obsługi dużej liczby aplikacji klienckich, umożliwiając wielu obiektom połączeń korzystanie z tego samego połączenia fizycznego, a tym samym obniżając łączną liczbę połączeń fizycznych z serwerem bazy danych.

Równoważenie obciążeń sysplex produktu sterownika uniwersalnego JDBC DB2 może poprawić dostępność grupy współużytkowania danych, ponieważ sterownik uzyskuje często informacje o statusie elementów tej grupy. Na podstawie tych informacji sterownik wyznacza element grupy współużytkowania danych, do którego powinna zostać skierowana następna transakcja. Dzięki równoważeniu obciążeń sysplex serwer DB2 UDB for z/OS i program Workload Manager dla systemu z/OS (WLM) zapewniają, że praca jest wydajnie rozkładana na elementy grupy współużytkowania danych i że w przypadku wystąpienia niepowodzenia na jednym elemencie grupy współużytkowania danych praca zostanie przeniesiona do innego elementu.

Sterownik uniwersalny JDBC DB2 oferuje obiekty transportu i globalną pulę obiektów transportu do obsługi koncentratora połączeń i równoważenia obciążeń sysplex. Każdemu fizycznemu połączeniu z serwerem bazy danych odpowiada jeden obiekt transportu. Włączając koncentrator połączeń i równoważenie obciążeń sysplex, podaje się maksymalną liczbę obiektów transportu, a tym samym ustawia się maksymalną liczbę połączeń fizycznych z serwerem bazy danych w dowolnym momencie.

Na poziomie sterownika ograniczenia liczby obiektów transportu można ustawić przy użyciu właściwości konfiguracyjnych sterownika uniwersalnego JDBC DB2.

Na poziomie połączenia można włączać i wyłączać koncentrator połączeń sterownika uniwersalnego JDBC DB2 i równoważenie obciążeń sysplex oraz ustawiać limity liczby obiektów transportu przy użyciu właściwości obiektu DataSource.

Globalną pulę obiektów transportu można monitorować w jeden z następujących sposobów:

używając śledzenia uruchamianego przy użyciu właściwości konfiguracyjnych sterownika uniwersalnego JDBC DB2,
używając aplikacyjnego interfejsu programistycznego (API).

Właściwości konfiguracyjne sterownika uniwersalnego JDBC DB2 dotyczące koncentratora połączeń i równoważenia obciążeń sysplex

Wszystkie poniższe właściwości konfiguracyjne są zawiązane z koncentratorem połączeń i równoważeniem obciążeń sysplex.

db2.jcc.dumpPool

Określa typy statystyk zapisywanych dla zdarzeń globalnej puli transportu oprócz zapisywanych statystyk podsumowujących. Globalna pula transportu jest używana do obsługi koncentratora połączeń i równoważenia obciążeń sysplex.

Typem danych właściwości db2.jcc.dumpPool jest liczba całkowita (int). Zanim zostaną zapisane jakiekolwiek statystyki, należy ustawić również właściwości konfiguracyjne db2.jcc.dumpPoolStatisticsOnSchedule i db2.jcc.dumpPoolStatisticsOnScheduleFile.

Za pomocą właściwości db2.jcc.dumpPool można określić jedną lub kilka spośród następujących typów statystyk:

DUMP_REMOVE_OBJECT (szesnastkowo: X'01', dziesiętnie: 1)
DUMP_GET_OBJECT (szesnastkowo: X'02', dziesiętnie: 2)
DUMP_WAIT_OBJECT (szesnastkowo: X'04', dziesiętnie: 4)
DUMP_SET_AVAILABLE_OBJECT (szesnastkowo: X'08', dziesiętnie: 8)
DUMP_CREATE_OBJECT (szesnastkowo: X'10', dziesiętnie: 16)
DUMP_SYSPLEX_MSG (szesnastkowo: X'20', dziesiętnie: 32)
DUMP_POOL_ERROR (szesnastkowo: X'80', dziesiętnie: 128)

Aby śledzić jeden lub wiele typów zdarzeń, należy dodać wartości tych typów zdarzeń do śledzenia. Załóżmy na przykład, że chcemy śledzić zdarzenia DUMP_GET_OBJECT i DUMP_CREATE_OBJECT. Liczbowymi odpowiednikami tych wartości są 2 i 16, a więc dla właściwości db2.jcc.dumpPool należy podać wartość 18.

Wartością domyślną jest 0. Oznacza ona, że dla globalnej puli transportu zapisywane będą tylko statystyki podsumowujące.

db2.jcc.dumpPoolStatisticsOnSchedule

Określa, jak często (w sekundach) statystyki globalnej puli transportu są zapisywane w pliku podanym we właściwości konfiguracyjnej db2.jcc.dumpPoolStatisticsOnScheduleFile. Globalna pula transportu jest używana do obsługi koncentratora połączeń i równoważenia obciążeń sysplex.

Wartością domyślną jest -1. Oznacza ona, że statystyki globalnej puli transportu nie są zapisywane.

db2.jcc.dumpPoolStatisticsOnScheduleFile

Określa nazwę pliku, do którego zapisywane są statystyki globalnej puli transportu. Globalna pula transportu jest używana do obsługi koncentratora połączeń i równoważenia obciążeń sysplex.

Jeśli właściwość konfiguracyjna db2.jcc.dumpPoolStatisticsOnScheduleFile nie zostanie określona, statystyki globalnej puli transportu nie będą zapisywane.

db2.jcc.maxTransportObjectIdleTime

Określa czas (w sekundach), przez jaki nieużywany obiekt transportu pozostaje w globalnej puli transportu, zanim zostanie z niej usunięty. Obiekty transportu są używane do obsługi koncentratora połączeń i równoważenia obciążeń sysplex.

Wartość domyślna właściwości konfiguracyjnej db2.jcc.maxTransportObjectIdleTime wynosi 60. Nadanie właściwości db2.jcc.maxTransportObjectIdleTime wartości mniejszej niż 0 spowoduje natychmiastowe usuwanie z puli nieużywanych obiektów transportu. To działanie jest niezalecane, ponieważ jego skutkiem może być poważne pogorszenie wydajności.

db2.jcc.maxTransportObjectWaitTime

Określa maksymalny czas (w sekundach), przez jaki aplikacja czeka na obiekt transportu po osiągnięciu wartości właściwości db2.jcc.maxTransportObjects. Obiekty transportu są używane do obsługi koncentratora połączeń i równoważenia obciążeń sysplex. Gdy aplikacja czeka dłużej niż wartość db2.jcc.maxTransportObjectWaitTime, globalna pula obiektów transportu generuje wyjątek SQLException.

Wartość domyślna właściwości konfiguracyjnej db2.jcc.maxTransportObjectWaitTime wynosi -1. Liczba ujemna oznacza, że aplikacja czeka przez czas nieograniczony.

db2.jcc.maxTransportObjects

Określa górne ograniczenie liczby obiektów transportu w globalnej puli obiektów transportu dla koncentratora połączeń i równoważenia obciążeń sysplex. Gdy liczba obiektów transportu w puli osiągnie wartość db2.jcc.maxTransportObjects, obiekty transportu, które nie były używane dłużej niż wartość db2.jcc.maxTransportObjectIdleTime, są usuwane z puli.

Wartością domyślną właściwości konfiguracyjnej db2.jcc.maxTransportObjects jest -1. Oznacza ona, że liczba obiektów transportu w globalnej puli obiektów transportu nie jest ograniczana.

db2.jcc.minTransportObjects

Określa dolne ograniczenie liczby obiektów transportu w globalnej puli obiektów transportu dla koncentratora połączeń i równoważenia obciążeń sysplex. W chwili tworzenia wirtualnej maszyny języka Java (JVM) w puli nie ma żadnych obiektów transportu. Są one dodawane do puli dopiero wtedy, gdy są potrzebne. Po osiągnięciu wartości db2.jcc.minTransportObjects liczba obiektów transportu w globalnej puli obiektów transportu nie spada nigdy poniżej wartości db2.jcc.minTransportObjects podczas działania tej maszyny JVM.

Wartością domyślną właściwości konfiguracyjnej db2.jcc.minTransportObjects jest 0. Każda wartość mniejsza lub równa 0 oznacza, że globalna pula obiektów transportu może stać się pusta.

Właściwości obiektu DataSource sterownika uniwersalnego JDBC DB2 dotyczące koncentratora połączeń i równoważenia obciążeń sysplex

Wszystkie poniższe właściwości obiektu DataSource sterownika uniwersalnego JDBC DB2 są związane z koncentratorem połączeń i równoważeniem obciążeń sysplex.

enableConnectionConcentrator

Informuje, czy jest włączona funkcja koncentratora połączeń sterownika uniwersalnego JDBC DB2. Funkcja koncentratora połączeń jest dostępna tylko dla połączeń z serwerami DB2 UDB for z/OS.

Właściwość enableConnectionConcentrator jest typu boolowskiego. Wartością domyślną jest false. Jeśli jednak właściwość enableSysplexWLB jest ustawiona na true, wartością domyślną jest true.

enableSysplexWLB

Informuje, czy jest włączona funkcja równoważenia obciążeń sysplex sterownika uniwersalnego JDBC DB2. Funkcja równoważenia obciążeń sysplex jest dostępna tylko dla połączeń z serwerami DB2 UDB for z/OS.

Właściwość enableSysplexWLB jest typu boolowskiego. Wartością domyślną jest false. Jeśli jednak właściwość enableSysplexWLB jest ustawiona na true, właściwość enableConnectionConcentrator jest domyślnie równa true.

maxTransportObjects

Określa liczbę obiektów transportu, których można używać dla wszystkich połączeń z powiązanym obiektem DataSource. Obiekty transportu są używane do obsługi koncentratora połączeń i równoważenia obciążeń sysplex. Wartość maxTransportObjects jest ignorowana, jeśli właściwości enableConnectionConcentrator lub enableSysplexWLB nie są ustawione w sposób umożliwiający korzystanie z koncentratora połączeń i równoważenia obciążeń sysplex.

Typem danych tej właściwości jest liczba całkowita (int).

Jeśli wartość maxTransportObjects nie zostanie osiągnięta i obiekt transportu będzie niedostępny w globalnej puli obiektów transportu, pula utworzy nowy obiekt transportu. Gdy zostanie osiągnięta wartość maxTransportObjects, aplikacja czeka przez czas określony we właściwości konfiguracyjnej db2.jcc.maxTransportObjectWaitTime. Jeśli po tym czasie nadal nie będzie dostępnego obiektu transportu w puli, pula wygeneruje wyjątek SQLException.

Właściwość maxTransportObjects nie przesłania właściwości konfiguracyjnej db2.jcc.maxTransportObjects. Właściwość maxTransportObjects nie wpływa na połączenia z innych obiektów DataSource. Jeśli wartość maxTransportObjects jest większa niż db2.jcc.maxTransportObjects, wartość maxTransportObjects nie zwiększa wartości db2.jcc.maxTransportObjects.

Wartością domyślną właściwości maxTransportObjects jest -1. Oznacza ona, że liczba obiektów transportu dla obiektu DataSource jest ograniczona tylko przez wartość db2.jcc.maxTransportObjects dla sterownika.

Przykład włączania funkcji koncentratora połączeń i równoważenia obciążeń sysplex sterownika uniwersalnego JDBC DB2 w serwerze WebSphere Application Server

Poniższa procedura stanowi przykład włączania funkcji koncentratora połączeń i równoważenia obciążeń sysplex sterownika uniwersalnego JDBC DB2 za pomocą serwera WebSphere^(R) Application Server.

Wymagania wstępne

Wymagania serwera:

WLM for z/OS,
DB2 UDB for OS/390^(R) and z/OS, wersja 7 lub nowsza.

Wymagania klienta:

sterownik uniwersalny JDBC DB2 na poziomie pakietu poprawek 10,
WebSphere^(R) Application Server, wersja 5.1 lub nowsza.

Procedura

Aby włączyć funkcje koncentratora połączeń i równoważenia obciążeń sysplex sterownika uniwersalnego JDBC DB2 za pomocą serwera WebSphere Application Server:

Upewnij się, że sterownik uniwersalny JDBC DB2 jest na poprawnym poziomie, zapewniającym obsługę funkcji koncentratora połączeń i równoważenia obciążeń sysplex, wydając następującą komendę w procesorze wiersza komend systemu z/OS lub w usługach systemowych w systemie UNIX^(R):
```
java com.ibm.db2.jcc.DB2Jcc -version
```
Znajdź w wynikach tej komendy wiersz podobny do tego:
```
[ibm][db2][jcc] Driver: IBM DB2 JDBC Universal Driver Architecture n n
```
n powinno wskazywać wersję 2.7 lub późniejszą.
Ustaw właściwości konfiguracyjne sterownika uniwersalnego JDBC DB2 tak, aby włączyć funkcję koncentratora połączeń lub równoważenia obciążeń sysplex dla wszystkich instancji obiektu DataSource utworzonych pod kontrolą sterownika.
Ustaw właściwości konfiguracyjne w pliku DB2JccConfiguration.properties.
1. Utwórz nowy lub zmień istniejący plik DB2JccConfiguration.properties.
2. Ustaw następujące właściwości konfiguracyjne:
  - db2.jcc.minTransportObjects
  - db2.jcc.maxTransportObjects
  - db2.jcc.maxTransportObjectWaitTime
  - db2.jcc.dumpPool
  - db2.jcc.dumpPoolStatisticsOnScheduleFile
  Zacznij od ustawień podobnych do następujących:
```
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. Dodaj ścieżkę katalogu do pliku DB2JccConfiguration.properties do ścieżki klas sterownika uniwersalnego JDBC DB2 serwera WebSphere Application Server.

Ustaw właściwości źródła danych sterownika uniwersalnego JDBC DB2 tak, aby włączyć funkcje koncentratora połączeń lub równoważenia obciążeń sysplex.

W konsoli administracyjnej serwera WebSphere Application Server ustaw następujące właściwości dla źródła danych, za pomocą którego aplikacja łączy się z serwerem bazy danych:

enableSysplexWLB
enableConnectionConcentrator
maxTransportObjects

Załóżmy, że chcemy włączyć zarówno funkcję koncentratora połączeń, jak i funkcję równoważenia obciążeń sysplex. Zacznij od ustawień podobnych do następujących:

Tabela 26. Przykład ustawień właściwości źródła danych dla funkcji koncentratora połączeń i równoważenia obciążeń sysplex sterownika uniwersalnego JDBC DB2.
Właściwość	Ustawienie
enableSysplexWLB	true¹
maxTransportObjects	100
Uwagi: Właściwość enableConnectionConcentrator ma domyślnie wartość true, ponieważ właściwość enableSysplexWLB ma wartość true.

Zrestartuj serwer WebSphere Application Server.

Metody monitorowania funkcji koncentratora połączeń i równoważenia obciążeń sysplex sterownika uniwersalnego JDBC DB2

Do monitorowania funkcji koncentratora połączeń i równoważenia obciążeń sysplex sterownika uniwersalnego JDBC DB2 konieczne jest monitorowanie globalnej puli obiektów transportu. Globalną pulę obiektów transportu można monitorować w jeden z następujących sposobów:

używając śledzenia uruchamianego przez ustawianie właściwości konfiguracyjnych sterownika uniwersalnego JDBC DB2,
używając aplikacyjnego interfejsu programistycznego (API).

Właściwości konfiguracyjne używane do monitorowania globalnej puli obiektów transportu

Śledzeniem globalnej puli obiektów transportu sterują właściwości konfiguracyjne db2.jcc.dumpPool, db2.jcc.dumpPoolStatisticsOnSchedule i db2.jcc.dumpPoolStatisticsOnScheduleFile.

Na przykład poniższy zestaw ustawień właściwości konfiguracyjnych powoduje zapisywanie komunikatów o błędach sysplex i komunikatów o błędach puli zrzutu co 60 sekund w pliku o nazwie /home/WAS/logs/srv1/poolstats:

db2.jcc.dumpPool=DUMP_SYSPLEX_MSG|DUMP_POOL_ERROR
db2.jcc.dumpPoolStatisticsOnSchedule=60
db2.jcc.dumpPoolStatisticsOnScheduleFile=/home/WAS/logs/srv1/poolstats

Wpis w pliku statystyki puli wygląda mniej więcej tak:

time Scheduled PoolStatistics npr:2575 nsr:2575 lwroc:439 
hwroc:1764 coc:372 aooc:362 rmoc:362 nbr:2872 tbt:857520 tpo:10

Znaczenia pól są następujące:

npr: Łączna liczba żądań, które sterownik uniwersalny JDBC DB2 przesłał do puli od czasu jej utworzenia.
nsr: Liczba pomyślnych żądań, które sterownik uniwersalny JDBC DB2 przesłał do puli od czasu jej utworzenia. Pomyślne żądanie to takie, w wyniku którego pula zwróciła obiekt.
lwroc: Liczba obiektów, które zostały ponownie wykorzystane, ale nie znajdowały się w puli. Może się tak zdarzyć, gdy obiekt połączenia zwolni obiekt transportu na granicy transakcji. Jeśli obiekt połączenia potrzebuje obiektu transportu później, a oryginalny obiekt transportu nie został użyty przez żaden inny obiekt połączenia, obiekt połączenia może go ponownie wykorzystać.
hwroc: Liczba ponownie wykorzystanych obiektów z puli.
coc: Liczba obiektów, które sterownik uniwersalny JDBC DB2 utworzył od czasu utworzenia puli.
aooc: Liczba obiektów, które przekroczyły czas bezczynności określony we właściwości konfiguracyjnej db2.jcc.maxTransportObjectIdleTime i zostały usunięte z puli.
rmoc: Liczba obiektów, które zostały usunięte z puli od czasu jej utworzenia.
nbr: Liczba żądań, które sterownik uniwersalny JDBC DB2 wysłał do puli, a które zostały zablokowane przez pulę z powodu osiągnięcia jej maksymalnej pojemności. Zablokowane żądanie może być pomyślne, jeśli obiekt zostanie zwrócony do puli przed przekroczeniem wartości konfiguracyjnej db2.jcc.maxTransportObjectWaitTime i wygenerowaniem wyjątku.
tbt: Łączny czas w milisekundach dla żądań, które zostały zablokowane przez pulę. Ten czas może być dużo większy niż czas wykonywania aplikacji, jeśli aplikacja korzysta z wielu wątków.
tpo: Liczba obiektów, które obecnie znajdują się w puli.

Aplikacyjne interfejsy programistyczne do monitorowania globalnej puli obiektów transportu

Można pisać aplikacje gromadzące dane statystyczne związane z globalną pulą obiektów transportu. Aplikacje te tworzą obiekty klasy DB2PoolMonitor i wywołują odpowiednie metody do pobierania informacji na temat puli.

Na przykład poniższy kod tworzy obiekt do monitorowania globalnej puli obiektów transportu:

import com.ibm.db2.jcc.DB2PoolMonitor;
DB2PoolMonitor transportObjectPoolMonitor =  
	DB2PoolMonitor.getPoolMonitor (DB2PoolMonitor.TRANSPORT_OBJECT);

Po utworzeniu obiektu DB2PoolMonitor do monitorowania globalnej puli obiektów transportu można używać następujących metod.

getMonitorVersion

Format:

public int getMonitorVersion()

Pobiera wersję klasy DB2PoolMonitor dostarczaną ze sterownikiem uniwersalnym JDBC DB2.

totalRequestsToPool

Format:

public int totalRequestsToPool()

Pobiera łączną liczbę żądań, które sterownik uniwersalny JDBC DB2 wysłał do puli od czasu jej utworzenia.

successfullRequestsFromPool

Format:

public int successfullRequestsFromPool()

Pobiera liczbę pomyślnych żądań, które sterownik uniwersalny JDBC DB2 wysłał do puli od czasu jej utworzenia. Pomyślne żądanie to takie, w wyniku którego pula zwróciła obiekt.

numberOfRequestsBlocked

Format:

public int numberOfRequestsBlocked()

Pobiera liczbę żądań, wysłanych do puli przez sterownik uniwersalny JDBC DB2, które zostały zablokowane z powodu osiągnięcia maksymalnej pojemności puli. Zablokowane żądanie może być pomyślne, jeśli obiekt zostanie zwrócony do puli przed przekroczeniem wartości konfiguracyjnej db2.jcc.maxTransportObjectWaitTime i wygenerowaniem wyjątku.

totalTimeBlocked

Format:

public long totalTimeBlocked()

Pobiera łączny czas - w milisekundach - dla żądań, które zostały zablokowane przez pulę. Ten czas może być dużo większy niż czas wykonywania aplikacji, jeśli aplikacja korzysta z wielu wątków.

lightWeightReusedObjectCount

Format:

public int lightWeightReusedObjectCount()

Pobiera liczbę obiektów, które zostały ponownie wykorzystane, ale nie znajdowały się w puli. Może się tak zdarzyć, gdy obiekt połączenia zwolni obiekt transportu na granicy transakcji. Jeśli obiekt połączenia potrzebuje obiektu transportu później, a oryginalny obiekt transportu nie został użyty przez żaden inny obiekt połączenia, obiekt połączenia może go ponownie wykorzystać.

heavyWeightReusedObjectCount

Format:

public int heavyWeightReusedObjectCount()

Pobiera liczbę ponownie wykorzystanych obiektów z puli.

createdObjectCount

Format:

public int createdObjectCount()

Pobiera liczbę obiektów, które sterownik uniwersalny JDBC DB2 utworzył od czasu utworzenia puli.

agedOutObjectCount

Format:

public int agedOutObjectCount()

Pobiera liczbę obiektów, dla których został przekroczony czas bezczynności, określony we właściwości konfiguracyjnej db2.jcc.maxTransportObjectIdleTime, i które zostały usunięte z puli.

removedObjectCount

Format:

public int removedObjectCount()

Pobiera liczbę obiektów, które zostały usunięte z puli od czasu jej utworzenia.

totalPoolObjects

Format:

public int totalPoolObjects()

Liczba obiektów, które obecnie znajdują się w puli.

Parametr konfiguracyjny OleDbReportIsLongForLongTypes interfejsu CLI/ODBC

Słowo kluczowe OleDbReportIsLongForLongTypes jest obsługiwane w następujących serwerach baz danych:

DB2 UDB for z/OS, wersja 6 z poprawką PTF UQ93891,
DB2 UDB for z/OS, wersja 7 z poprawką PTF UQ93889,
DB2 UDB for z/OS, wersja 8 z poprawką PTF UQ93890,
DB2 UDB for Linux, UNIX and Windows, wersja 8.2 (odpowiednik wersji 8.1 z pakietem poprawek 7) i nowsze.

Opis parametru:: Powoduje oznaczanie przez OLE DB typów danych LONG za pomocą opcji DBCOLUMNFLAGS_ISLONG.
Składnia parametru w pliku db2cli.ini:: OleDbReportIsLongForLongTypes = 0 | 1
Równoważny atrybut instrukcji:: SQL_ATTR_REPORT_ISLONG_FOR_LONGTYPES_OLEDB
Ustawienie domyślne:: Typy LONG (LONG VARCHAR, LONG VARCHAR FOR BIT DATA, LONG VARGRAPHIC i LONG VARGRAPHIC FOR BIT DATA) nie mają ustawionej opcji DBCOLUMNFLAGS_ISLONG, co może powodować użycie kolumn w klauzuli WHERE.
Informacja o użyciu:

Mechanizm kursora klienta OLE DB i obiekt CommandBuilder dostawcy danych OLE DB dla platformy .NET generują aktualizację i usuwają instrukcje w oparciu o informacje w kolumnie udostępniane przez dostawcę IBM DB2 OLE DB. Jeśli wygenerowana instrukcja zawiera typ LONG w klauzuli WHERE, wykonanie instrukcji zakończy się niepowodzeniem, ponieważ typy LONG nie mogą być używane w wyszukiwaniu z operatorem równości. Ustawienie parametru OleDbReportIsLongForLongTypes na 1 spowoduje zgłaszanie przez dostawcę IBM DB2 OLE DB typów LONG (LONG VARCHAR, LONG VARCHAR FOR BIT DATA, LONG VARGRAPHIC i LONG VARGRAPHIC FOR BIT DATA) przy ustawionej opcji DBCOLUMNFLAGS_ISLONG. Uniemożliwi to stosowanie długich kolumn w klauzuli WHERE.

Parametr konfiguracyjny CLI/ODBC OleDbSQLColumnsSortByOrdinal

Słowo kluczowe OleDbSQLColumnsSortByOrdinal jest obsługiwane w następujących serwerach baz danych:

DB2 UDB for z/OS, wersja 6 z poprawką PTF UQ93891,
DB2 UDB for z/OS, wersja 7 z poprawką PTF UQ93889,
DB2 UDB for z/OS, wersja 8 z poprawką PTF UQ93890,
DB2 UDB for Linux, UNIX and Windows, wersja 8.2 (odpowiednik wersji 8.1 z pakietem poprawek 7) i nowsze.

Opis parametru:: Powoduje zwrócenie przez komendę OLE DB IDBSchemaRowset::GetRowset(DBSCHEMA_COLUMNS) zestawu wierszy posortowanych według kolumny ORDINAL_POSITION.
Składnia parametru w pliku db2cli.ini:: OleDbSQLColumnsSortByOrdinal = 0 | 1
Równoważny atrybut instrukcji:: SQL_ATTR_SQLCOLUMNS_SORT_BY_ORDINAL_OLEDB
Ustawienie domyślne:: Komenda IDBSchemaRowset::GetRowset(DBSCHEMA_COLUMNS) zwraca zestaw wierszy posortowanych według kolumn TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME.
Informacja o użyciu:

Specyfikacja Microsoft OLE DB wymaga, aby komenda IDBSchemaRowset::GetRowset(DBSCHEMA_COLUMNS) zwracała zestaw wierszy posortowany według kolumn TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME. Dostawca IBM DB2 OLE DB jest zgodny z tą specyfikacją. Jednak aplikacje, które używają dostawcy mostu ODBC firmy Microsoft, zazwyczaj są kodowane tak, aby pobierać zestaw wierszy posortowany według kolumny ORDINAL_POSITION. Nadanie parametrowi OleDbSQLColumnsSortByOrdinal wartości 1 spowoduje, że dostawca zwróci zestaw wierszy posortowany według kolumny ORDINAL_POSITION.

Grupa właściwości DB2 Data Source dla dostawcy IBM DB2 OLE DB

Dostawca IBM DB2 OLE DB ma dodatkową grupę właściwości: DB2 Data Source. Zestawem właściwości dla źródła danych DB2 jest DBPROPSET_DB2DATASOURCE.

Identyfikatorem GUID dla zestawu właściwości jest {0x8a80412a,0x7d94,0x4fec,{0x87,0x3e,0x6c,0xd1,0xcd,0x42,0x0d,0xcd}}

Zestaw DBPROPSET_DB2DATASOURCE ma trzy właściwości:

DB2PROP_REPORTISLONGFORLONGTYPES
DB2PROP_RETURNCHARASWCHAR
DB2PROP_SORTBYORDINAL

DB2PROP_REPORTISLONGFORLONGTYPES

#define DB2PROP_REPORTISLONGFORLONGTYPES 4
Grupa właściwości: DB2 Data Source 
Zestaw właściwości: DB2PROPSET_DATASOURCE
Typ: VT_BOOL
Typowy odczyt/zapis: R/W
Opis: Zgłasza wartość IsLong dla typów Long

Tabela 27. Wartości właściwości DB2PROP_REPORTISLONGFORLONGTYPES.
Wartości	Znaczenie
VARIANT_TRUE	Powoduje zgłaszanie przez dostawcę IBM DB2 OLE DB typów LONG (LONG VARCHAR, LONG VARCHAR FOR BIT DATA, LONG VARGRAPHIC i LONG VARGRAPHIC FOR BIT DATA) przy ustawionej opcji DBCOLUMNFLAGS_ISLONG. Uniemożliwi to stosowanie długich kolumn w klauzuli WHERE.
VARIANT_FALSE	Opcja DBCOLUMNFLAGS_ISLONG nie jest ustawiana dla typów LONG VARCHAR, LONG VARCHAR FOR BIT DATA, LONG VARGRAPHIC i LONG VARGRAPHIC FOR BIT DATA. Jest to ustawienie domyślne.

DB2PROP_RETURNCHARASWCHAR

#define DB2PROP_RETURNCHARASWCHAR 2
Grupa właściwości: DB2 Data Source 
Zestaw właściwości: DB2PROPSET_DATASOURCE
Typ: VT_BOOL
Typowy odczyt/zapis: R/W
Opis: Zwraca typ Char jako WChar

Tabela 28. Wartości właściwości DB2PROP_RETURNCHARASWCHAR.
Wartości	Znaczenie
VARIANT_TRUE	Aplikacja OLE DB opisuje kolumny typu CHAR, VARCHAR, LONG VARCHAR i CLOB jako DBTYPE_WSTR. W funkcji ISequentialStream przyjmuje się, że dane są w stronie kodowej UCS-2. Jest to ustawienie domyślne.
VARIANT_FALSE	Aplikacja OLE DB opisuje kolumny typu CHAR, VARCHAR, LONG VARCHAR i CLOB jako DBTYPE_STR. W funkcji ISequentialStream przyjmuje się, że dane są w lokalnej stronie kodowej klienta.

DB2PROP_SORTBYORDINAL

#define DB2PROP_SORTBYORDINAL 3
Grupa właściwości: DB2 Data Source 
Zestaw właściwości: DB2PROPSET_DATASOURCE
Typ: VT_BOOL
Typowy odczyt/zapis: R/W
Opis: Sortuje według typu Ordinal

Tabela 29. Wartości właściwości DB2PROP_SORTBYORDINAL.
Wartości	Znaczenie
VARIANT_TRUE	Powoduje, że dostawca zwraca zestaw wierszy posortowany według kolumny ORDINAL_POSITION.
VARIANT_FALSE	Powoduje, że dostawca zwraca zestaw wierszy posortowany według kolumn TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME. Jest to ustawienie domyślne.

Niepoprawna składnia adresu URL w diagramie składni programu DB2Binder

W temacie "Installing the DB2 Universal JDBC Driver", diagram składni programu DB2Binder niepoprawnie definiuje składnię adresu URL dla sterownika uniwersalnego JDBC DB2. Poprawna reprezentacja składni adresu URL dla programu DB2Binder została przedstawiona na poniższym diagramie:

Składnia programu DB2Binder

>>-java--com.ibm.db2.jcc.DB2Binder------------------------------>
 
>---url jdbc:db2://serwer-+---------+-/baza_danych-------------->
                          '-:--port-'
 
>---user ID-użytkownika---password hasło------------------------>
 
>--+------------------------+--+----------------------------+--->
   '--size liczba całkowita-'  '--collection nazwa-kolekcji-'
 
>--+----------------------------------+--+-------+-------------><
   |              .-,---------------. |  '--help-'
   |              V                 | |
   '--tracelevel ---opcja-śledzenia-+-'

Przekierowanie klientów sterownika uniwersalnego JDBC DB2

Opcja automatycznego przekierowania klienta w programie DB2 Universal Database (UDB) dla systemów Linux, UNIX i Windows umożliwia aplikacjom klienckim odtworzenie stanu po przerwaniu połączenia z serwerem, dzięki czemu mogą one kontynuować działanie po minimalnej przerwie.

Za każdym razem, kiedy serwer zablokuje się, każdy połączony z tym serwerem klient odbiera komunikat o błędzie komunikacji, który powoduje przerwanie połączenia i błąd aplikacji. W systemach, w których duże znaczenie ma dostępność, konieczne są konfiguracje nadmiarowe lub obsługa przełączania awaryjnego. (Przełączanie awaryjne jest to możliwość przejęcia przez inny serwer operacji z serwera, który uległ awarii). W każdym przypadku klient sterownika uniwersalnego JDBC DB2 będzie próbował ponownie nawiązać połączenie z nowym lub oryginalnym serwerem, który może działać w węźle przełączania awaryjnego. Po ponownym nawiązaniu połączenia aplikacja odbiera wyjątek SQLException, który informuje o niepowodzeniu transakcji, ale może ona przystąpić do przetwarzania następnej transakcji.

Ograniczenia

Obsługa przekierowania klienta sterownika uniwersalnego JDBC DB2 jest dostępna tylko dla połączeń korzystających z interfejsu javax.sql.DataSource.
Zanim aplikacja kliencka będzie mogła odtworzyć stan po utracie łączności, należy na serwerze określić położenie serwera alternatywnego. Administrator bazy danych określa serwer alternatywny za pomocą komendy UPDATE ALTERNATE SERVER FOR DATABASE.

Procedura

Gdy administrator bazy danych określi położenie serwera alternatywnego dla konkretnej bazy danych w instancji serwera, informacje o serwerze podstawowym i alternatywnym są zwracane do klienta w czasie połączenia. Sterownik uniwersalny JDBC DB2 tworzy instancję umożliwiającego odwołania obiektu DB2ClientRerouteServerList i zapisuje tę instancję w pamięci przejściowej. W przypadku przerwania połączenia sterownik uniwersalny JDBC DB2 próbuje ponownie nawiązać połączenie za pomocą informacji o serwerze zwróconych z serwera.

Właściwość clientRerouteServerListJNDIName obiektu DataSource udostępnia dodatkowe możliwości obsługi przekierowania klienta; ma ona dwie funkcje:

umożliwia zachowanie trwałości informacji o serwerze alternatywnym na wirtualnych maszynach Java (JVM),
dostarcza informacji o położeniu serwera alternatywnego w przypadku, gdy pierwsze połączenie z serwerem bazy danych nie powiedzie się.

Właściwość clientRerouteServerListJNDIName identyfikuje odwołanie JNDI do instancji DB2ClientRerouteServerList w repozytorium JNDI informacji o serwerach alternatywnych. Po pomyślnym połączeniu z serwerem głównym informacje o serwerze alternatywnym dostarczane przez właściwość clientRerouteServerListJNDIName są zastępowane informacjami z serwera. Po przełączeniu awaryjnym sterownik uniwersalny JDBC DB2 spróbuje przekazać zaktualizowane informacje do repozytorium JNDI, jeśli została zdefiniowana właściwość clientRerouteServerListJNDIName. Jeśli właściwość clientRerouteServerListJNDIName została określona, do połączenia zostaną użyte informacje o serwerze głównym określone we właściwości DB2ClientRerouteServerList. Jeśli serwer główny nie został określony, zostaną użyte informacje o nazwie serwera określone w źródle danych.

Instancja DB2ClientRerouteServerList to przekształcane do postaci szeregowej komponenty Java bean z czterema właściwościami:

alternateServerName
alternatePortNumber
primaryServerName
primaryPortNumber

Zostały udostępnione metody pobierania i ustawiania umożliwiające uzyskiwanie dostępu do tych właściwości. Definicja klasy DB2ClientRerouteServerList jest następująca:

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 (); 
}

Nowo nawiązane połączenie awaryjne jest skonfigurowane z oryginalnymi właściwościami źródła danych, za wyjątkiem nazwy serwera i numeru portu. Dodatkowo wszelkie rejestry specjalne programu DB2 UDB, które zostały zmodyfikowane podczas oryginalnego połączenia, są ponownie ustawiane podczas przełączenia awaryjnego przez sterownik uniwersalnego JDBC DB2.

Gdy nastąpi awaria połączenia, sterownik uniwersalny JDBC DB2 najpierw próbuje odtworzyć połączenie z serwerem głównym. Jeśli przełączenie awaryjne nie powiedzie się, sterownik spróbuje połączyć się z serwerem alternatywnym (przełączenie awaryjne). Po ponownym nawiązaniu połączenia sterownik zwraca do aplikacji wyjątek java.sql.SQLException z kodem SQLCODE -4498, który informuje aplikację, że połączenie zostało automatycznie ponownie nawiązane z serwerem alternatywnym. Aplikacja może wówczas próbować ponownie przetworzyć tę transakcję.

Procedura utrwalania obiektu DB2ClientRerouteServerList

W celu skonfigurowania pamięci masowej tak, aby obiekt DB2ClientRerouteServerList był trwały, należy wykonać następujące czynności:

Utwórz instancję obiektu DB2ClientRerouteServerList i powiąż ją z rejestrem JNDI. Na przykład:

// Utwórz kontekst początkowy dla operacji nadawania nazw
InitialContext registry = new InitialContext();
// Utwórz obiekt DB2ClientRerouteServerList
DB2ClientRerouteServerList address=new DB2ClientRerouteServerList();

// Ustaw numer portu i nazwę serwera głównego
address.setPrimaryPortNumber(50000);
address.setPrimaryServerName("mvs1.sj.ibm.com");

// Ustaw numer portu i nazwę serwera alternatywnego
int[] port = {50002};
String[] server = {"mvs3.sj.ibm.com"};
address.setAlternatePortNumber(port);
address.setAlternateServerName(server);
    
registry.rebind("serverList", address);

Przypisz nazwę JNDI obiektu DB2ClientRerouteServerList do właściwości clientRerouteServerListJNDIName obiektu DataSource. Na przykład:
```
datasource.setClientRerouteServerListJNDIName("serverList");
```

Dostosowywanie właściwości konfiguracyjnych sterownika uniwersalnego JDBC DB2

Właściwości konfiguracyjne sterownika uniwersalnego JDBC DB2 umożliwiają ustawienie wartości właściwości o zasięgu obejmującym cały zakres działania sterownika. Ustawienia te dotyczą instancji obiektu DataSource i aplikacji. Ich wartości można zmieniać bez konieczności modyfikowania kodu źródłowego aplikacji ani charakterystyk obiektu DataSource.

Każde ustawienie właściwości konfiguracyjnych sterownika uniwersalnego JDBC DB2 ma następującą formę:

właściwość=wartość

Jeśli nazwa właściwości konfiguracyjnej rozpoczyna się od łańcucha db2.jcc.override, właściwość ta dotyczy wszystkich połączeń i przesłania ona wszystkie właściwości obiektu Connection lub DataSource o tej samej nazwie. Jeśli nazwa właściwości konfiguracyjnej rozpoczyna się od łańcucha db2.jcc lub db2.jcc.default, wartość tej właściwości jest wartością domyślną. Ustawienia właściwości obiektu Connection lub DataSource przesłaniają tę wartość.

Procedura

Aby ustawić właściwości konfiguracyjne:

Ustaw właściwości konfiguracyjne jako właściwości systemowe Java. Ustawienia te przesłaniają wszystkie inne ustawienia.
Dla autonomicznych aplikacji Java można ustawić właściwości konfiguracyjne jako właściwości systemowe Java, określając parę -Dwłaściwość=wartość dla każdej właściwości konfiguracyjnej podczas wykonywania komendy java.
Ustaw właściwości konfiguracyjne w zasobie, którego nazwę zawiera właściwość systemowa Java db2.jcc.propertiesFile. Jako wartość właściwości db2.jcc.propertiesFile można na przykład podać nazwę pełnej ścieżki.
Dla autonomicznych aplikacji Java można ustawić właściwości konfiguracyjne, określając opcję -Ddb2.jcc.propertiesFile=ścieżka podczas wykonywania komendy java.
Ustaw właściwości konfiguracyjne w zasobie o nazwie podanej we właściwości DB2JccConfiguration.properties. Do znalezienia zasobu określonego we właściwości DB2JccConfiguration.properties używane jest standardowe wyszukiwanie zasobów Java. Sterownik uniwersalny JDBC DB2 szuka tego zasobu tylko wtedy, gdy nie została ustawiona właściwość systemowa Java db2.jcc.propertiesFile.
Zasób DB2JccConfiguration.properties może być autonomicznym plikiem lub częścią pliku archiwum JAR.

Jeśli zasób DB2JccConfiguration.properties jest autonomicznym plikiem, ścieżka będąca wartością właściwości DB2JccConfiguration.properties musi wchodzić w skład konkatenacji CLASSPATH.

Jeśli zasób DB2JccConfiguration.properties znajduje się w pliku JAR, plik ten musi być częścią konkatenacji CLASSPATH.

Poniżej zostały wymienione właściwości konfiguracyjne sterownika uniwersalnego JDBC DB2, które można ustawić. Wszystkie właściwości są opcjonalne.

db2.jcc.override.traceFile

Umożliwia sterownikowi uniwersalnemu JDBC DB2 śledzenie kodu sterownika Java i określa nazwę, w oparciu o którą tworzone są nazwy plików śledzenia.

Jako wartość właściwości db2.jcc.override.traceFile należy podać pełną nazwę pliku.

Właściwość db2.jcc.override.traceFile przesłania właściwość obiektu Connection lub DataSource.

Na przykład poniższe ustawienie właściwości db2.jcc.override.traceFile umożliwia śledzenie przez sterownik uniwersalny JDBC DB2 kodu Java i zapisywanie jego wyników w pliku o nazwie /SYSTEM/tmp/jdbctrace:

db2.jcc.override.traceFile=/SYSTEM/tmp/jdbctrace

Właściwości śledzenia należy ustawiać zgodnie z zaleceniami działu wsparcia firmy IBM.

db2.jcc.sqljUncustomizedWarningOrException

Określa działanie realizowane przez sterownik uniwersalny JDBC DB2 podczas pracy niedostosowanej aplikacji SQLJ. Właściwość db2.jcc.sqljUncustomizedWarningOrException może mieć następujące wartości:

0: Sterownik uniwersalny JDBC DB2 nie generuje ostrzeżenia ani wyjątku podczas pracy niedostosowanej aplikacji SQLJ. Jest to ustawienie domyślne.
1: Sterownik uniwersalny JDBC DB2 generuje ostrzeżenie podczas pracy niedostosowanej aplikacji SQLJ.
2: Sterownik uniwersalny JDBC DB2 generuje wyjątek podczas pracy niedostosowanej aplikacji SQLJ.

Usunięto funkcję db2secFreeToken

Funkcja db2secFreeToken (zwalnianie pamięci zajmowanej przez token) nie jest już częścią interfejsu API db2secGssapiServerAuthFunctions_1 modułu dodatkowego uwierzytelniania użytkownika.

Niestandardowe dodatkowe moduły zabezpieczeń należy wdrażać uważnie

Integralność instalacji programu DB2 Universal Database (UDB) może zostać naruszona, jeśli wdrażane dodatkowe moduły zabezpieczeń nie zostaną odpowiednio zakodowane, sprawdzone i przetestowane. Program DB2 UDB jest zabezpieczony przed wieloma często spotykanymi typami awarii, ale nie może on zagwarantować kompletnej integralności w przypadku wdrażania napisanych przez użytkownika dodatkowych modułów zabezpieczeń.

Moduły dodatkowe zabezpieczeń

Gdy korzysta się z własnego, dostosowanego modułu dodatkowego zabezpieczeń, w instrukcjach połączenia uruchamianych za pośrednictwem procesora CLP lub dynamicznej instrukcji SQL można posługiwać się identyfikatorem użytkownika o długości 255 znaków.

Funkcje API modułów dodatkowych zabezpieczeń

Dla funkcji API db2secGetGroupsForUser, db2secValidatePassword i db2secGetAuthIDs parametr wejściowy nazwa_bazy_danych może mieć wartość NULL, a odpowiadającemu mu parametrowi wejściowemu długości długość_nazwy_bazy_danych zostanie nadana wartość 0.

Konwencje nazewnictwa w dodatkowych modułach zabezpieczeń (systemy Linux i UNIX)

Rozszerzenie .so jest teraz akceptowanym rozszerzeniem nazw plików bibliotek napisanych przez użytkowników dodatkowych modułów zabezpieczeń na wszystkich platformach systemów Linux i UNIX.

W systemie AIX biblioteki dodatkowych modułów zabezpieczeń mogą mieć rozszerzenie .a lub .so. Jeśli istnieją obie wersje biblioteki modułów dodatkowych, używana jest wersja z rozszerzeniem .a.

W systemach HP-UX na platformie PA-RISC biblioteki dodatkowych modułów zabezpieczeń mogą mieć rozszerzenie .sl lub .so. Jeśli istnieją obie wersje biblioteki modułów dodatkowych, używana jest wersja z rozszerzeniem .sl.

Na wszystkich pozostałych platformach systemów Linux i UNIX jedynym obsługiwanym rozszerzeniem nazw plików bibliotek dodatkowych modułów zabezpieczeń jest .so.

Ograniczenia dotyczące bibliotek dodatkowych modułów zabezpieczeń

W systemie AIX biblioteki dodatkowych modułów zabezpieczeń mogą mieć rozszerzenie nazwy pliku .a lub .so. To, który mechanizm ładujący biblioteki modułów dodatkowych zostanie użyty, zależy od używanego rozszerzenia:

Biblioteki modułów dodatkowych z rozszerzeniem nazwy pliku .a

Zakłada się, że biblioteki modułów dodatkowych z rozszerzeniem nazwy pliku .a to archiwa zawierające elementy obiektów współużytkowanych. Elementy te muszą nosić nazwy shr.o (32-bitowe) lub shr64.o (64-bitowe). Pojedyncze archiwum może zawierać elementy zarówno 32-bitowe, jak i 64-bitowe, co umożliwia wdrażanie ich na platformach obu typów.

Na przykład w celu zbudowania 32-bitowej biblioteki modułu dodatkowego typu archiwum należy wpisać:

  xlc_r -qmkshrobj -o shr.o MojModulDodatkowy.c
        -bE:MojModulDodatkowy.exp
  ar rv MojModulDodatkowy.a shr.o

Biblioteki modułów dodatkowych z rozszerzeniem nazwy pliku .so

Zakłada się, że biblioteki modułów dodatkowych z rozszerzeniem nazwy pliku .so to ładowane dynamicznie obiekty współużytkowane. Taki obiekt może być 32-bitowy lub 64-bitowy, zależnie od opcji kompilatora i konsolidatora użytych podczas budowania. Na przykład w celu zbudowania 32-bitowej biblioteki modułu dodatkowego należy wpisać:

  xlc_r -qmkshrobj -o MojModulDodatkowy.so MojModulDodatkowy.c
        -bE:MojModulDodatkowy.exp

Na wszystkich platformach z wyjątkiem systemu AIX zawsze zakłada się, że biblioteki modułów dodatkowych są dynamicznie ładowanymi obiektami współużytkowanymi.

| | |

Obsługa modułu dodatkowego GSS-API dla sterownika uniwersalnego JDBC DB2

Po wprowadzeniu programu DB2 UDB, wersja 8.2, dla systemów Linux, UNIX, Windows można tworzyć własne mechanizmy uwierzytelniania w postaci modułów dodatkowych (bibliotek ładowalnych). Mechanizm DB2 UDB ładuje i uzyskuje dostęp do tych modułów dodatkowych w celu przeprowadzenia uwierzytelnienia użytkownika. W celu zapewnienia obsługi aplikacji klienta napisanej w języku Java sterownik uniwersalny JDBC DB2 zapewnia obsługę dodatkowych modułów zabezpieczeń w programie DB2 UDB, wersja 8.2, pakiet poprawek 4.

W aplikacjach w języku Java używających sterownika uniwersalnego JDBC DB2 do przeprowadzania uwierzytelniania za pomocą modułu dodatkowego użytkownicy muszą zaimplementować własny moduł dodatkowy, rozszerzając klasę abstrakcyjną com.ibm.db2.jcc.DB2JCCPlugin i ustawiając następujące właściwości:

Identyfikator użytkownika i hasło: są to referencje użytkownika wykorzystywane podczas uwierzytelniania

Nazwa modułu dodatkowego: określa nazwę modułu dodatkowego po stronie serwera

Mechanizm zabezpieczenia: należy ustawić na zabezpieczenie przy użyciu modułu dodatkowego

Moduł dodatkowy: określa moduł dodatkowy po stronie aplikacji klienckiej

Przykład:

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

Dodatkowe moduły zabezpieczeń GSS-API nie obsługują uwierzytelniania wieloprzepływowego

Uwierzytelnianie GSS-API jest ograniczone do przepływu jednego tokenu od klienta do serwera i jednego tokenu z serwera do klienta. Te tokeny są uzyskiwane w wyniku wykonania funkcji gss_init_sec_context() u klienta i funkcji gss_accept_sec_context() na serwerze. Moduły dodatkowe GSS-API próbujące stosować dodatkowe przepływy spowodują wygenerowanie nieoczekiwanego błędu dodatkowego modułu zabezpieczeń, co spowoduje zerwanie połączenia.

Dodatkowe moduły zabezpieczeń GSS-API nie obsługują szyfrowania i podpisywania komunikatów

Dodatkowe moduły zabezpieczeń GSS-API nie udostępniają szyfrowania i podpisywania komunikatów.

Niejawne kończenie transakcji w aplikacjach autonomicznych

Każde zakończenie działania aplikacji (normalne i nieprawidłowe) powoduje niejawnie wycofanie niezakończonych jednostek pracy, niezależnie od systemu operacyjnego.

Obsługa transakcji rozproszonych

W dokumentacji Co nowego dla programu DB2 Universal Database (UDB), wersja 8.2, informacje o obsłudze transakcji rozproszonych w sekcji dotyczącej rozszerzeń sterownika uniwersalnego JDBC DB2 są niepoprawne. Niepoprawne jest ostatnie zdanie tej sekcji. Poprawne informacje zostały podane poniżej:

Poczynając od wersji 8.2 program DB2 UDB udostępnia obsługę rozproszonego przetwarzania transakcyjnego, które jest zgodne ze specyfikacją XA. Ta obsługa implementuje specyfikacje Java 2 Platform Enterprise Edition (J2EE) Java Transaction Service (JTS) i Java Transaction API (JTA).

[ Początek strony |Poprzednia strona | Następna strona | Spis treści ]