|
DB2 Universal JDBC-styreprogram støtter ikke type 4-tilknytning til DB2 |for VM/VSE-databaser. I emnene "Setting up the Windows Java environment" |og "Installing the DB2 Universal JDBC Driver" i boken Application |Development Guide: Programming Client Applications, og DB2 UDB Informasjonssenter |står det feilaktig at DB2 Universal JDBC-styreprogram støtter type |4-tilknytning til DB2 for VM/VSE-databaser.
Java-applikasjoner som bruker DB2 Universal JDBC Driver type 4 connectivity for å få tilgang til DB2 UDB for z/OS-tjenere, kan dra nytte av tilkoblingskonsentratoren og funksjonene for banalsering av Sysplex-arbeidsbelastning.
Disse funksjonene likner på tilkoblingskonsentratoren og funksjonene for balansering av Sysplex-arbeidsbelastning i DB2 Connect.
DB2 Universal JDBC-styreprogram-tilkoblingskonsentratoren kan redusere ressursene DB2 UDB for z/OS-databasetjenere trenger for å støtte et stort antall klientapplikasjoner, ved å la mange tilkoblingsobjekter bruke den samme fysiske tilkoblingen, slik at antall fysiske tilkoblinger til databasetjeneren reduseres.
Balansering av DB2 Universal JDBC-styreprogram Sysplexarbeidsbelastning kan gi bedre tilgjengelighet for en datadelingsgruppe, fordi styreprogrammet henter statusinformasjon om medlemmene i en datadelingsgruppe ofte. Styreprogrammet bruker denne informasjonen til å avgjøre hvilken datadelingsmedlem den neste transaksjonen skal rutes til. Med balansering av Sysplex-arbeidsbelastning sikrer DB2 UDB for z/OS-tjeneren og Workload Manager for z/OS (WLM) at arbeid blir distribuert effektivt blant medlemmer i datadelingsgruppe, og at arbeid blir overført til et annet medlem i en datadelingsgruppe hvis det oppstår en feil hos et medlem.
DB2 Universal JDBC-styreprogram bruker transportobjekter og en globalt transportobjektgruppe til å støtte tilkoblingskonsentratoren og balansering av Sysplex-arbeidsbelastning. Det er ett transportobjekt for hver fysiske tilkobling til databasetjeneren. Når du aktiverer tilkoblingskonsentratoren og balansering av Sysplex-arbeidsbelastning, definerer du det maksimale antall fysiske tilkoblinger til databasetjeneren som kan finnes på samme tid, ved å definere det maksimale antall transportobjekter.
På styreprogramnivå definerer du grenser for antall transportobjekter ved hjelp av konfigurasjonsegenskapene for DB2 Universal JDBC-styreprogram.
På tilkoblingsnivå aktiverer eller deaktiverer du DB2 Universal JDBC-styreprogram-tilkoblingskonsentratoren og balansering av Sysplex-arbeidsbelastning og definerer grenser for antall transportobjekter som bruker DataSource-egenskaper.
Du kan overvåke den globale transportobjektgruppen på disse måtene:
Konfigurasjonsegenskapene nedenfor blir brukt til tilkoblingskonsentratoren og banalsering av Sysplex-arbeidsbelastning
The data type of db2.jcc.dumpPool is integer (int.). The db2.jcc.dumpPoolStatisticsOnSchedule and db2.jcc.dumpPoolStatisticsOnScheduleFile configuration properties must also be set for writing statistics before any statistics are written.
You can specify one or more of the following types of statistics with the db2.jcc.dumpPool property:
To trace more than one type of event, add the values for the types of events that you want to trace. For example, suppose that you want to trace DUMP_GET_OBJECT and DUMP_CREATE_OBJECT events. The numeric equivalents of these values are 2 and 16, so you specify 18 for the db2.jcc.dumpPool value.
The default is 0, which means that only summary statistics for the global transport pool are written.
The default is -1, which means that global transport pool statistics are not written.
If the db2.jcc.dumpPoolStatisticsOnScheduleFile configuration property is not specified, global transport pool statistics are not written.
The default value for the db2.jcc.maxTransportObjectIdleTime configuration property is 60. Setting db2.jcc.maxTransportObjectIdleTime to a value less than 0 causes unused transport objects to be deleted from the pool immediately. This action is not recommended because it can cause severe performance degradation.
The default value for the db2.jcc.maxTransportObjectWaitTime configuration property is -1. Any negative value means that applications wait forever.
The default value for the db2.jcc.maxTransportObjects configuration property is -1, which means that there is no limit to the number of transport objects in the global transport object pool.
The default value for the db2.jcc.minTransportObjects configuration property is 0. Any value less than or equal to 0 means that the global transport object pool can become empty.
DB2 Universal JDBC-styreprogram DataSource-egenskapene nedenfor blir brukt til tilkoblingskonsentratoren og banalsering av Sysplex-arbeidsbelastning
The data type of the enableConnectionConcentrator property is boolean. The default is false. However, if enableSysplexWLB is set to true, the default is true.
The data type of the enableSysplexWLB property is boolean. The default is false. However, if enableSysplexWLB is set to true, enableConnectionConcentrator is set to true by default.
The data type of this property is integer (int.).
If the maxTransportObjects value has not been reached and a transport object is not available in the global transport objects pool, the pool creates a new transport object. If the maxTransportObjects value has been reached, the application waits for the amount of time that is specified by the db2.jcc.maxTransportObjectWaitTime configuration property. After that amount of time has elapsed, if there is still no available transport object in the pool, the pool throws an SQLException.
The maxTransportObjects property does not override the db2.jcc.maxTransportObjects configuration property. The maxTransportObjects property has no effect on connections from other DataSource objects. If the maxTransportObjects value is larger than the db2.jcc.maxTransportObjects value, maxTransportObjects does not increase the db2.jcc.maxTransportObjects value.
The default value for the maxTransportObjects property is -1, which means that the number of transport objects for the DataSource is limited only by the db2.jcc.maxTransportObjects value for the driver..
Prosedyren nedenfor er et eksempel på hvordan du aktiverer funksjonene for DB2 Universal JDBC-styreprogram-tilkoblingskonsentrator og balansering av Sysplex-arbeidsbelastning med WebSphere Application Server.
Krav til tjener:
Krav til klient:
Slik aktiverer du funksjonene for DB2 Universal JDBC-styreprogram-tilkoblingskonsentrator og balansering av Sysplex-arbeidsbelastning med WebSphere Application Server:
java com.ibm.db2.jcc.DB2Jcc -versionFinn en linje i utdataene som ser omtrent slik ut:
[ibm][db2][jcc] Driver: IBM DB2 JDBC Universal Driver Architecture n nn skal være 2.7 eller senere.
Definer konfigurasjonsegenskapene i en DB2JccConfiguration.properties-fil.
db2.jcc.minTransportObjects=0 db2.jcc.maxTransportObjects=1500 db2.jcc.maxTransportObjectWaitTime=-1 db2.jcc.dumpPool=0 db2.jcc.dumpPoolStatisticsOnScheduleFile= /home/WAS/logs/srv1/poolstats
I administrasjonskonsollen for WebSphere Application Server definerer du følgende egenskaper for datakilden som applikasjonen din bruker til å koble seg til databasetjeneren:
Hvis du skal overvåke DB2 Universal JDBC-styreprogram-tilkoblingskonsentratoren og funksjonene for balansering av Sysplex-arbeidsbelastning, må du overvåke den globale transportobjektgruppen (global transport objects pool). Du kan overvåke den globale transportobjektgruppen på disse måtene:
Konfigurasjonsegenskapene db2.jcc.dumpPool, db2.jcc.dumpPoolStatisticsOnSchedule og db2.jcc.dumpPoolStatisticsOnScheduleFile styrer sporingen av den globale transportobjektgruppen.
Hvis du for eksempel definerer følgende konfigurasjonsegenskaper, blir Sysplex-feilmeldinger og dump pool-feilmeldinger skrevet hvert 60. sekund til filen /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
En oppføring i gruppestatistikkfilen ser slik ut:
time Scheduled PoolStatistics npr:2575 nsr:2575 lwroc:439
hwroc:1764 coc:372 aooc:362 rmoc:362 nbr:2872 tbt:857520 tpo:10Feltene har følgende betydning:
Du kan skrive applikasjoner for å samle inn statistikk på den globale transportobjektgruppen. Disse applikasjonene oppretter objekter i DB2PoolMonitor-klassen og starter metoder for å hente informasjon om gruppen.
For eksempel oppretter den følgende koden et objekt for overvåking av den globale transportobjektgruppen:
import com.ibm.db2.jcc.DB2PoolMonitor; DB2PoolMonitor transportObjectPoolMonitor = DB2PoolMonitor.getPoolMonitor (DB2PoolMonitor.TRANSPORT_OBJECT);
Etter at du har opprettet DB2PoolMonitor-objektet, kan du bruke disse metodene til å overvåke den globale transportobjektgruppen.
public int getMonitorVersion()
Henter den versjonen av DB2PoolMonitor-klassen som leveres med DB2 Universal JDBC-styreprogram.
public int totalRequestsToPool()
Henter det totale antall forespørsler som DB2 Universal JDBC-styreprogram har gjort til gruppen siden gruppen ble opprettet.
public int successfullRequestsFromPool()
Henter antall vellykkede forespørsler som DB2 Universal JDBC-styreprogram har gjort til gruppen siden gruppen ble opprettet. En vellykket forespørsel betyr at gruppen returnerte et objekt.
public int numberOfRequestsBlocked()
Henter antall forespørsler som DB2 Universal JDBC-styreprogram har gjort til gruppen, som gruppen blokkerte fordi gruppen har nådd maksimumskapasiteten sin. En blokkert forespørsel kan bli vellykket hvis et objekt blir returnert til grupen før verdien for konfigurasjonsegenskapen db2.jcc.maxTransportObjectWaitTime blir overskredet slik at det genereres et unntak.
public long totalTimeBlocked()
Henter den totale tiden i millisekunder for forespørsler som ble blokkert av gruppen. Denne tiden kan være mye større enn den medgåtte utføringstiden for applikasjonen hvis applikasjonen bruker flere tråder.
public int lightWeightReusedObjectCount()
Henter antall objekter som ble gjenbrukt, men som ikke var i gruppen. Dette kan oppstå hvis et tilkoblingsobjekt frigir et transportobjekt ved en transaksjonsgrense. Hvis tilkoblingsobjektet trenger et transportobjekt senere, og det opprinnelige transportobjektet ikke er brukt av et annet tilkoblingsobjekt, kan tilkoblingsobjektet bruke det transportobjektet.
public int heavyWeightReusedObjectCount()
Henter antall objekter som ble gjenbrukt fra gruppen.
public int createdObjectCount()
Henter antall objekter som DB2 Universal JDBC-styreprogram har opprettet siden gruppen ble opprettet.
public int agedOutObjectCount()
Henter antall objekter som overskred den uvirksomme tiden som er angitt av konfigurasjonsegenskapen db2.jcc.maxTransportObjectIdleTime og ble slettet fra gruppen.
public int removedObjectCount()
Henter antall objekter som er slettet fra gruppen siden gruppen ble opprettet.
public int totalPoolObjects()
Antall objekter som finnes i gruppen for øyeblikket.
Nøkkelordet OleDbReportIsLongForLongTypes støttes av følgende databasetjenere:
OLE DBs Client Cursor Engine og OLE DB .NET Data Providers CommandBuilder genererer oppdaterings- og slettesetninger basert på kolonneinformasjonen som blir gitt av IBM DB2 OLE DB Provider. Hvis den genererte setningen inneholder en LONG-type i WHERE-leddet, vil setningen mislykkes fordi LONG-typer ikke kan brukes i et søk med en likhetsoperator. Hvis nøkkelordet OleDbReportIsLongForLongTypes settes til 1, vil IBM DB2 OLE DB Provider rapportere LONG-typer (LONG VARCHAR, LONG VARCHAR FOR BIT DATA, LONG VARGRAPHIC og LONG VARGRAPHIC FOR BIT DATA) med DBCOLUMNFLAGS_ISLONG-flagget definert. Dette vil hindre at LONG-kolonnene blir brukt i WHERE-leddet.
Nøkkelordet OleDbSQLColumnsSortByOrdinal støttes av følgende databasetjenere:
Microsoft OLE DB-spesifikasjonen krever at IDBSchemaRowset::GetRowset(DBSCHEMA_COLUMNS) returnerer radsettet sortert etter kolonnene TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME. IBM DB2 OLE DB Provider følger denne spesifikasjonen. Applikasjoner som bruker Microsoft ODBC Bridge Provider (MSDASQL), er imidlertid vanligvis kodet for å hente radsettet sortert etter ORDINAL_POSITION. Hvis nøkkelordet OleDbSQLColumnsSortByOrdinal settes til 1, vil Provider returnere et radsett sortert etter ORDINAL_POSITION.
IBM DB2 OLE DB Provider har fått en ny egenskapsgruppe: DB2 Data Source. Egenskapssettet for DB2 Data Source er DBPROPSET_DB2DATASOURCE.
GUID for egenskapssettet er {0x8a80412a,0x7d94,0x4fec,{0x87,0x3e,0x6c,0xd1,0xcd,0x42,0x0d,0xcd}}
DBPROPSET_DB2DATASOURCE har tre egenskaper:
#define DB2PROP_REPORTISLONGFORLONGTYPES 4 Egenskapsgruppe: DB2 Data Source Egenskapssett: DB2PROPSET_DATASOURCE Type: VT_BOOL Vanlig R/W: R/W Beskrivelse: Rapporter IsLong for Long-typer
OLE DBs Client Cursor Engine og OLE DB .NET Data Providers CommandBuilder genererer oppdaterings- og slettesetninger basert på kolonneinformasjonen som blir gitt av IBM DB2 OLE DB Provider. Hvis den genererte setningen inneholder en LONG-type i WHERE-leddet, vil setningen mislykkes fordi LONG-typer ikke kan brukes i et søk med en likhetsoperator.
| Verdier | Betydning |
|---|---|
| VARIANT_TRUE | Gjør at IBM DB2 OLE DB Provider rapporterer LONG-typer (LONG VARCHAR, LONG VARCHAR FOR BIT DATA, LONG VARGRAPHIC og LONG VARGRAPHIC FOR BIT DATA) med DBCOLUMNFLAGS_ISLONG-flagget definert. Dette vil hindre at LONG-kolonnene blir brukt i WHERE-leddet. |
| VARIANT_FALSE | DBCOLUMNFLAGS_ISLONG er ikke definert for LONG VARCHAR, LONG VARCHAR FOR BIT DATA, LONG VARGRAPHIC og LONG VARGRAPHIC FOR BIT DATA. Dette er standardverdien. |
#define DB2PROP_RETURNCHARASWCHAR 2 Egenskapsgruppe: DB2 Data Source Egenskapssett: DB2PROPSET_DATASOURCE Type: VT_BOOL Vanlig R/W: R/W Beskrivelse: Returner Char som WChar
| Verdier | Betydning |
|---|---|
| VARIANT_TRUE | OLE DB beskriver kolonner av typen CHAR, VARCHAR, LONG VARCHAR, eller CLOB som DBTYPE_WSTR. Kodesettet med data i forbindelse med ISequentialStream vil være UCS-2. Dette er standardverdien. |
| VARIANT_FALSE | OLE DB beskriver kolonner av typen CHAR, VARCHAR, LONG VARCHAR, eller CLOB som DBTYPE_STR. Kodesettet med data i forbindelse med ISequentialStream vil være det lokale kodesettet til klienten. |
#define DB2PROP_SORTBYORDINAL 3 Egenskapsgruppe: DB2 Data Source Egenskapssett: DB2PROPSET_DATASOURCE Type: VT_BOOL Vanlig R/W: R/W Beskrivelse: Sorter etter ordenstall
Microsoft OLE DB-spesifikasjonen krever at IDBSchemaRowset::GetRowset(DBSCHEMA_COLUMNS) returnerer radsettet sortert etter kolonnene TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME. IBM DB2 OLE DB Provider følger denne spesifikasjonen. Applikasjoner som bruker Microsoft ODBC Bridge Provider (MSDASQL), er imidlertid vanligvis kodet for å hente radsettet sortert etter ORDINAL_POSITION.
| Verdier | Betydning |
|---|---|
| VARIANT_TRUE | Gjør at Provider returnerer et radsett sortert etter ORDINAL_POSITION. |
| VARIANT_FALSE | Gjør at Provider returnerer et radsett sortert etter TABLE_CATALOG, TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME. Dette er standardverdien. |
I emnet "Installere DB2 Universal JDBC-styreprogrammet" har DB2Binder-syntaksdiagrammet en feil definisjon av URL-syntaksen for DB2 Universal JDBC-styreprogrammet. Dette er riktig URL-syntaks for DB2Binder:
|
Funksjonen for automatisk klientomdirigering i DB2 Universal Database (UDB) for Linux, UNIX, og Windows gjør det mulig for klientapplikasjoner å gjenopprette kommunikasjonen etter å ha mistet forbindelsen med tjeneren, slik at de kan fortsette uten lengre avbrudd.
Når en tjener låser seg, mottar klientene som er koblet til tjeneren en kommunikasjonsfeil som avslutter forbindelsen og resulterer i en applikasjonsfeil. Når tilgjengelighet er viktig, bør du ha et reserveoppsett eller failover-støtte. (Failover gjør at tjeneren kan ta over operasjonene når en annen tjener ikke fungerer.) I alle tilfeller prøver DB2 Universal JDBC-styreprogramklienten å gjenopprette forbindelsen til en ny tjener eller til den opprinnelige tjeneren som kanskje kjører på en failover-node. Når forbindelsen er gjenopprettet, mottar applikasjonen et SQL-unntak (exception) som informerer om transaksjonsfeilen, men applikasjonen kan fortsette med den neste transaksjonen.
Når den databaseansvarlige har oppgitt plasseringen til den alternative tjeneren på en bestemt database på tjenerforekomsten, blir plasseringen til den primære og alternative tjeneren returnert til klienten ved tilkobling. DB2 Universal JDBC-styreprogrammet oppretter en forekomst av Referenceable-objektet DB2ClientRerouteServerList og lagrer den forekomsten i sitt midlertidige minne. Hvis kommunikasjonen blir brutt, kan DB2 Universal JDBC-styreprogrammet gjenopprette forbindelsen ved hjelp av tjenerinformasjonen som blir returnert fra tjeneren.
Egenskapen clientRerouteServerListJNDIName DataSource sørger for utvidet støtte for klientomdirigering på klienten. clientRerouteServerListJNDIName har to funksjoner:
Egenskapen clientRerouteServerListJNDIName identifiserer en JNDI-referanse til en DB2ClientRerouteServerList-forekomst i et JNDI-datalager for opplysninger om alternative tjenere. Når forbindelsen til den primære tjeneren er opprettet, blir opplysningene om den alternative tjeneren som er gitt av clientRerouteServerListJNDIName overskrevet av opplysningene fra tjeneren. DB2 Universal JDBC-styreprogrammet prøver å propagere den oppdaterte informasjonen til JNDI-lageret etter en failover hvis egenskapen clientRerouteServerListJNDIName er definert. Hvis clientRerouteServerListJNDIName er oppgitt, vil informasjonen for den primære tjeneren som er oppgitt i DB2ClientRerouteServerList, bli brukt for tilkoblingen. Hvis den primære tjeneren ikke er oppgitt, brukes serverName-informasjonen som er oppgitt på datakilden.
DB2ClientRerouteServerList er en seriell Java-bønne med fire egenskaper:
Det finnes getter- og setter-metoder for å bruke disse egenskapene. Definisjonen av DB2ClientRerouteServerList-klassen er slik:
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 ();
}
En failover-forbindelse som nettopp er opprettet, konfigureres med de opprinnelige DataSource-egenskapene bortsett i fra tjenernavnet og portnummeret. I tillegg blir eventuelle DB2 UDB-spesialregistre som ble endret under den opprinnelige forbindelsen, gjenopprettet i failover-forbindelsen av DB2 Universal Driver JDBC-styreprogrammet.
Når det oppstår en kommunikasjonsfeil, prøver først DB2 Universal JDBC-styreprogrammet en gjenoppretting mot den primære tjeneren. Hvis dette mislykkes, prøver styreprogrammet å koble til den alternative plasseringen (failover). Når forbindelsen er gjenopprettet, sender styreprogrammet en java.sql.SQLException til applikasjonen med SQLCODE -4498, for å fortelle applikasjonen at forbindelsen er automatisk gjenopprettet til den alternative tjeneren. Applikasjonen kan deretter prøve å utføre transaksjonen på nytt.
Slik gjør du DB2ClientRerouteServerList fast (persistent):
// Create a starting context for naming operations
InitialContext registry = new InitialContext();
// Create a DB2ClientRerouteServerList object
DB2ClientRerouteServerList address=new DB2ClientRerouteServerList();
// Set the port number and server name for the primary server
address.setPrimaryPortNumber(50000);
address.setPrimaryServerName("mvs1.sj.ibm.com");
// Set the port number and server name for the alternate server
int[] port = {50002};
String[] server = {"mvs3.sj.ibm.com"};
address.setAlternatePortNumber(port);
address.setAlternateServerName(server);
registry.rebind("serverList", address);
datasource.setClientRerouteServerListJNDIName("serverList");Konfigurasjonsegenskapene for DB2 Universal JDBC-styreprogrammet gjør at du kan definere verdier som gjelder for hele styreprogrammet. Innstillingene gjelder på tvers av applikasjoner og DataSource-forekomster. Du kan endre innstillingene uten å endre kildekode for applikasjoner eller DataSource-egenskaper.
Konfigurasjonsegenskapene for DB2 Universal JDBC-styreprogrammet har dette formatet:
egenskap=verdi
Hvis konfigurasjonsegenskapen begynner med db2.jcc.override, gjelder den for alle forbindelser og overstyrer alle Connection- eller DataSource-egenskaper med samme egenskapnavn. Hvis konfigurasjonsegenskapen begynner med db2.jcc eller db2.jcc.default, er den en standardverdi. Innstillingene for Connection- og DataSource-egenskaper overstyrer denne verdien.
Slik definerer du konfigurasjonsegenskaper:
For frittstående Java-applikasjoner kan du definere konfigurasjonsegenskapene som Java-systemegenskaper ved å oppgi -Dproperty=verdi for hver konfigurasjonsegenskap når du utfører java-kommandoen.
For frittstående Java-applikasjoner kan du definere konfigurasjonsegenskapene ved å oppgi alternativet -Ddb2.jcc.propertiesFile=path når du utfører java-kommandoen.
DB2JccConfiguration.properties kan være en frittstående fil eller den kan være en del av en JAR-fil.
Hvis DB2JccConfiguration.properties er en frittstående fil, må banen til filen være definert av CLASSPATH.
Hvis DB2JccConfiguration.properties er en del av en JAR-fil, må JAR-filen være definert av CLASSPATH.
Du kan definere disse konfigurasjonsegenskapene for DB2 Universal JDBC-styreprogrammet: Alle egenskapene er valgfrie.
Oppgi et fullstendig filnavn for verdien til egenskapen db2.jcc.override.traceFile.
Egenskapen db2.jcc.override.traceFile overstyrer traceFile-egenskapen for et Connection- eller DataSource-objekt.
Hvis du for eksempel oppgir denne innstillingen for db2.jcc.override.traceFile, aktiveres sporing av Java-koden for DB2 Universal JDBC-styreprogrammet til en fil med navnet /SYSTEM/tmp/jdbctrace:
db2.jcc.override.traceFile=/SYSTEM/tmp/jdbctrace
Du bør definere sporingsegenskapene i følge instruksjoner fra IBM Kundeservice.
Funksjonen db2secFreeToken (ledig minne holdt av symbol) er ikke lenger en del av brukerautentiseringstilleggsmodul-APIen db2secGssapiServerAuthFunctions_1.
Integriteten til DB2 Universal Database-installasjonen kan bli skadet hvis koding, kontroll og testing ikke er tilfredsstillende utført før man tar i bruk en tilleggsmodul for sikkerhet. DB2 UDB har beskyttelse mot mange vanlige typer feil, men det er ikke mulig å garantere ubrutt integritet når det tas i bruk en egenutviklet tilleggsmodul for sikkerhet i systemet.
Hvis du bruker din egen tilpassede tilleggsmodul for sikkerhet, kan du bruke bruker-IDer på opptil 255 tegn i en tilkoblingssetning som blir sendt gjennom kommandolinjebehandleren (CLP) eller en dynamisk SQL-setning.
For APIene db2secGetGroupsForUser, db2secValidatePassword og db2secGetAuthIDs kan inndataparameteren dbname være null, og den tilsvarende inndataparameteren dbnamelen for lengden blir da satt til 0.
.so blir nå godtatt som filtype for brukerskrevne biblioteker for sikkerhetstilleggsmoduler på alle Linux- og UNIX-plattformer.
På AIX kan bibliotekene for sikkerhetstilleggsmoduler ha filtypen .a eller .so. Hvis begge versjonene av biblioteket finnes, brukes biblioteket som har filtypen .a.
For HP-UX på PA-RISC kan bibliotekene for sikkerhetstilleggsmoduler ha filtypen .sl eller .so. Hvis begge versjonene av biblioteket finnes, brukes biblioteket som har filtypen .sl.
På alle andre Linux- og UNIX-plattformer er .so den eneste filtypen som er støttet for biblioteker for sikkerhetstilleggsmoduler.
På AIX kan bibliotekene for sikkerhetstilleggsmoduler ha filtypen .a eller .so. Mekanismen som brukes til å laste inn tilleggsmodulbiblioteket er avhengig av hvilken filtype som brukes:
Hvis du for eksempel vil bygge et 32-biters tilleggsmodulbibliotek av arkivtypen, oppgir du:
xlc_r -qmkshrobj -o shr.o MyPlugin.c -bE:MyPlugin.exp ar rv MyPlugin.a shr.o
xlc_r -qmkshrobj -o MyPlugin.so MyPlugin.c -bE:MyPlugin.exp
På alle andre plattformer enn AIX behandles alltid bibliotekene for sikkerhetsmoduler som dynamisk lastbare felles objekter.
| | |Fra og med DB2 UDB versjon 8.2 for Linux, UNIX og Windows, kan du opprette egne |autentiseringsmekanismer i form av tilleggsmoduler (lastbare biblioteker). DB2 UDB-programmet laster |inn og tar i bruk disse tilleggsmodulene for å utføre brukerautentisering. For å støtte kundeapplikasjoner som |er skrevet i Java, har DB2 Universal JDBC-styreprogram støtte for sikkerhetstilleggsmoduler i DB2 UDB |V8.2, opprettingspakke 4.
|For Java-applikasjoner som bruker DB2 Universal JDBC-styreprogram til å utføre autentisering med |en tilleggsmodul, må brukerne implementere sin egen tilleggsmodul ved å utvide (extend) |abstraktklassen com.ibm.db2.jcc.DB2JCCPlugin og definere følgende egenskaper:
|Eksempel:
|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);
GSS-API-autentisering er begrenset til å flytte (flow) ett symbol (token) fra klienten til tjeneren og ett symbol fra tjeneren til klienten. Disse symbolene blir hentet fra gss_init_sec_context() på klienten og fra gss_accept_sec_context() på tjeneren. GSS-API-tilleggsmoduler som prøver på flere flytinger (flows) vil generere en uventet feil for sikkerhetsmodulen, slik at tilkoblingen brytes.
Meldingskryptering og -signering er ikke tilgjengelig i GSS-API-tilleggsmoduler for sikkerhet.
Alle applikasjonsavslutninger (normale og unormale) tilbakestiller implisitt alle utestående arbeidsenheter, uansett operativsystem.
I dokumentet Nyheter for DB2 Universal Database (UDB) versjon 8.2 har avsnittet om forbedringer i distribuert transaksjonsstøtte for DB2 Universal JDBC-styreprogrammet feil informasjon. Den siste setningen i dette avsnittet er feil. Dette er riktig informasjon:
Fra og med versjon 8.2 har DB2 UDB støtte for distribuert transaksjonsbehandling som følger XA-spesifikasjonen. Denne støtten implementerer Java 2 Platform, Enterprise Edition (J2EE) Java Transaction Service (JTS) og Java Transaction API (JTA)-spesifikasjoner.
[ Øverst på siden |Forrige side | Neste side | Innhold ]