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.
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:
Wszystkie poniższe właściwości konfiguracyjne są zawiązane z koncentratorem połączeń i równoważeniem 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:
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.
Wartością domyślną jest -1. Oznacza ona, że statystyki globalnej puli transportu nie są zapisywane.
Jeśli właściwość konfiguracyjna db2.jcc.dumpPoolStatisticsOnScheduleFile nie zostanie określona, statystyki globalnej puli transportu nie będą zapisywane.
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.
Wartość domyślna właściwości konfiguracyjnej db2.jcc.maxTransportObjectWaitTime wynosi -1. Liczba ujemna oznacza, że aplikacja czeka przez czas nieograniczony.
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.
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.
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.
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.
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.
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.
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 serwera:
Wymagania klienta:
Aby włączyć funkcje koncentratora połączeń i równoważenia obciążeń sysplex sterownika uniwersalnego JDBC DB2 za pomocą serwera WebSphere Application Server:
java com.ibm.db2.jcc.DB2Jcc -versionZnajdź w wynikach tej komendy wiersz podobny do tego:
[ibm][db2][jcc] Driver: IBM DB2 JDBC Universal Driver Architecture n nn powinno wskazywać wersję 2.7 lub późniejszą.
Ustaw właściwości konfiguracyjne w pliku DB2JccConfiguration.properties.
db2.jcc.minTransportObjects=0 db2.jcc.maxTransportObjects=1500 db2.jcc.maxTransportObjectWaitTime=-1 db2.jcc.dumpPool=0 db2.jcc.dumpPoolStatisticsOnScheduleFile= /home/WAS/logs/srv1/poolstats
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:
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:
Ś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:
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.
public int getMonitorVersion()
Pobiera wersję klasy DB2PoolMonitor dostarczaną ze sterownikiem uniwersalnym JDBC DB2.
public int totalRequestsToPool()
Pobiera łączną liczbę żądań, które sterownik uniwersalny JDBC DB2 wysłał do puli od czasu jej utworzenia.
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.
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.
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.
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ć.
public int heavyWeightReusedObjectCount()
Pobiera liczbę ponownie wykorzystanych obiektów z puli.
public int createdObjectCount()
Pobiera liczbę obiektów, które sterownik uniwersalny JDBC DB2 utworzył od czasu utworzenia puli.
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.
public int removedObjectCount()
Pobiera liczbę obiektów, które zostały usunięte z puli od czasu jej utworzenia.
public int totalPoolObjects()
Liczba obiektów, które obecnie znajdują się w puli.
Słowo kluczowe OleDbReportIsLongForLongTypes jest obsługiwane w następujących serwerach baz danych:
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.
Słowo kluczowe OleDbSQLColumnsSortByOrdinal jest obsługiwane w następujących serwerach baz danych:
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.
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:
#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
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.
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. |
#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
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. |
#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
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.
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. |
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:
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.
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:
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:
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ę.
W celu skonfigurowania pamięci masowej tak, aby obiekt DB2ClientRerouteServerList był trwały, należy wykonać następujące czynności:
// 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);
datasource.setClientRerouteServerListJNDIName("serverList");
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ść.
Aby ustawić właściwości konfiguracyjne:
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.
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.
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.
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.
Funkcja db2secFreeToken (zwalnianie pamięci zajmowanej przez token) nie jest już częścią interfejsu API db2secGssapiServerAuthFunctions_1 modułu dodatkowego uwierzytelniania użytkownika.
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ń.
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.
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.
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.
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:
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
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.
| | |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:
|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);
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 udostępniają szyfrowania i podpisywania komunikatów.
Każde zakończenie działania aplikacji (normalne i nieprawidłowe) powoduje niejawnie wycofanie niezakończonych jednostek pracy, niezależnie od systemu operacyjnego.
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 ]