|
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 Driver-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 Driver 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 Driver 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 Driver.
|På tilkoblingsnivå aktiverer eller deaktiverer du DB2 Universal JDBC Driver-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 Driver 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..
|The following procedure is an example of enabling the DB2 Universal JDBC Driver connection |concentrator and Sysplex workload balancing functions with WebSphere(R) |Application Server.
|Server requirements:
|Client requirements:
|Slik aktiverer du DB2 Universal JDBC Driver-tilkoblingskonsentratoren og funksjoner for balansering av Sysplex-arbeidsbelastning med WebSphere Application Server:
|java com.ibm.db2.jcc.DB2Jcc -versionFind a line in the output |like this: |
[ibm][db2][jcc] Driver: IBM DB2 JDBC Universal Driver Architecture n nn should be 2.7 or later.
Set the configuration properties in a DB2JccConfiguration.properties |file.
|db2.jcc.minTransportObjects=0 |db2.jcc.maxTransportObjects=1500 |db2.jcc.maxTransportObjectWaitTime=-1 |db2.jcc.dumpPool=0 |db2.jcc.dumpPoolStatisticsOnScheduleFile= | /home/WAS/logs/srv1/poolstats
In the WebSphere Application Server |administrative console, set the following properties for the data source that |your application uses to connect to the database server:
|Hvis du skal overvåke DB2 Universal JDBC Driver-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:10
Feltene 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 Driver.
|public int totalRequestsToPool()|
Henter det totale antall forespørsler som DB2 Universal JDBC Driver har gjort til gruppen siden gruppen ble opprettet.
|public int successfullRequestsFromPool()|
Henter antall vellykkede forespørsler som DB2 Universal JDBC Driver 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 Driver 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 Driver 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.
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 ]