Konfigurationsunterschiede zwischen WebSphere Application Server Traditional und Liberty: Elemente "dataSource" und "jdbcDriver"
Es gibt einige Unterschiede, die bei der Konfiguration von dataSource in Liberty und Datenquellen in WebSphere Application Server Traditional zu beachten sind.
- Datenquelleneigenschaften mit unterschiedlichen Namen
- ifxIFX_LOCK_MODE_WAIT entspricht informixLockModeWait in WebSphere Application Server Traditional.
- supplementalJDBCTrace entspricht supplementalTrace in WebSphere Application Server Traditional.
- transactional entspricht nonTransactionalDataSource in WebSphere Application Server Traditional.
- isolationLevel entspricht webSphereDefaultIsolationLevel in WebSphere Application Server Traditional.
- queryTimeout entspricht webSphereDefaultQueryTimeout in WebSphere Application Server Traditional.
- id entspricht name in WebSphere Application Server Traditional.
- Datenquelleneigenschaften mit unterschiedlichen Werten
- beginTranForResultSetScrollingAPIs ist in Liberty standardmäßig true.
- beginTranForVendorAPIs ist in Liberty standardmäßig true.
- connectionSharing ist in Liberty standardmäßig MatchOriginalRequest.
- statementCacheSize entspricht einer JDBC-Providereigenschaft in WebSphere Application Server Traditional und einer dataSource-Eigenschaft in Liberty mit einem Standardwert von 10.
- Datenquelleneigenschaften in WebSphere Application Server Traditional ohne Liberty-Entsprechung
- category
- supportsDynamicUpdates
- Eigenschaft connectionSharing von Datenquellen
- In Liberty kann connectionSharing entweder mit MatchOriginalRequest oder mit MatchCurrentState konfiguriert werden. Standardmäßig wird MatchOriginalRequest verwendet.
- In WebSphere Application Server Traditional kann connectionSharing differenzierter konfiguriert werden, d. h., einzelne Verbindungseigenschaften können basierend auf der ursprünglichen Verbindungsanforderung oder auf dem aktuellen Status der Verbindung zugeordnet werden. In WebSphere Application Server Traditional ist connectionSharing eine Kombination von Bits, die die Verbindungseigenschaften darstellen, die auf der Basis des aktuellen Status der Verbindung zugeordnet werden sollen. In WebSphere Application Server Traditional steht der Wert "0" für die Zuordnung aller Eigenschaften auf der Basis der ursprünglichen Verbindungsanforderung. Der Wert -1 steht für die Zuordnung aller Eigenschaften auf Basis des aktuellen Status der Verbindung. Der Standardwert für WebSphere Application Server Traditional ist 1, d. h., die Isolationsstufe wird basierend auf dem aktuellen Status der Verbindung abgeglichen. Alle anderen Eigenschaften werden auf der Basis der ursprünglichen Verbindungsanforderung abgeglichen.
- Datenquelleneigenschaften für die ZeitdauerEigenschaften für die Zeitdauer können in Liberty optional mit Einheiten angegeben werden. Beispiel:
Im Abschnitt Java Database Connectivity 4.1 sind die zulässigen Zeiteinheiten und Formate des Elements dataSource beschrieben. Das Weglassen der Einheiten in Liberty entspricht der Verwendung der in WebSphere Application Server Traditional verwendeten Standardeinheiten.<dataSource id="informix" jndiName="jdbc/informix" queryTimeout="5m" ...> <properties.informix ifxIFX_LOCK_MODE_WAIT="120s" .../> </dataSource>
- Konfiguration für JDBC-Treiber
- In Liberty können Sie denselben Ansatz für die Konfiguration verschiedener jdbcDriver-Elemente für XA-fähige und nicht XA-fähige Datenquellenimplementierungsklassen verwenden. Alternativ können Sie ein einziges jdbcDriver-Element für beide Klassentypen verwenden. Die Definition mehrerer jdbcDriver-Elemente bewirkt nicht, dass unterschiedliche Klassenladeprogramme verwendet werden. In Liberty verwenden jdbcDriver-Elemente immer das Klassenladeprogramm der gemeinsam genutzten Bibliothek, mit der sie konfiguriert werden.
- In WebSphere Application Server Traditional wird ein JDBC-Provider definiert, der auf die JAR-Dateien, die komprimierten Dateien und die nativen Dateien des JDBC-Treibers verweist. Sie müssen gesonderte JDBC-Provider für XA-fähige und nicht XA-fähige Datenquellenimplementierungsklassen definieren.
Für einige der gängigen JDBC-Treiber leitet Liberty die Namen der Datenquellenimplementierungsklassen basierend auf den Namen der JAR-Dateien des Treibers ab. Deswegen können Sie die Implementierungsklassennamen weglassen. Beispiel:<jdbcDriver id="Derby" libraryRef="DerbyLib"/> <library id="DerbyLib"> <fileset dir="C:/Drivers/derby" includes="derby.jar" /> </library>
Verwenden Sie die optionalen Eigenschaften der Standardimplementierungsklassen, um diese Klassen, wie z. B. javax.sql.DataSource, javax.sql.ConnectionPoolDataSource und javax.sql.XADataSource, zu überschreiben.
Das folgende Beispiel veranschaulicht, wie die javax.sql.XADataSource- und javax.sql.ConnectionPoolDataSource-Standardimplementierungen, die von Liberty ausgewählt werden, überschrieben werden können.
Weitere Informationen zum Element jdbcDriver finden Sie unter Java Database Connectivity 4.1.<jdbcDriver id="Derby" libraryRef="DerbyLib" javax.sql.XADataSource="org.apache.derby.jdbc.EmbeddedXADataSource" javax.sql.ConnectionPoolDataSource="org.apache.derby.jdbc.EmbeddedConnectionPoolDataSource"/> <library id="DerbyLib"> <fileset dir="C:/Drivers/derby" includes="derby.jar" /> </library>