For access to relational databases, applications use the Java™ Database Connectivity (JDBC) drivers and data sources that you configure for the
application server.
Before you begin
Each vendor database requires different JDBC driver implementation classes for JDBC
connectivity. A JDBC provider encapsulates those vendor-specific driver files. Through the data
source that you associate with the JDBC provider, an application server obtains and manages the
physical connections for transactions between applications and the database. Attention: If you are accessing a DB2® database, IBM Optim pureQuery
Runtime is an alternative to JDBC. For more information on pureQuery, see the topic, Task overview:
IBM Optim pureQuery Runtime, in the related links section.
Before you start this task,
determine the version of data source that you need according to the API specification of your
applications.
Procedure
- Verify that all of the necessary JDBC driver files are installed on
your application server.
Consult the article, Data source minimum required settings, by
vendor for that information. If you opt to configure a user-defined JDBC provider, check your
database documentation for information about the driver files.
- Create a JDBC provider.
When you create a JDBC provider from the administrative console, see the topic, Configuring a
JDBC provider by using the administrative console; or
Using the wsadmin scripting client, see the topic, Configuring a JDBC provider by using the
scripting; or
Using the Java Management Extensions (JMX) API, see the
topic, Creating a JDBC provider and data source by using the JavaManagement Extensions API.
- Create a data source.
From the administrative console, see the topic, Creating a data source by using the
administrative console; or
Using the wsadmin scripting client, see the topic, Configuring new data sources by using
scripting. For V4 data sources, see the topic, Configuring new WAS40 data sources by using scripting
(deprecated); or
Using the JMX API, see the topic, Creating a JDBC provider and data source by using the JavaManagement Extensions API.
Required properties: Different database vendors require different
properties for implementations of their JDBC drivers. Set these properties on the WebSphere Application Server data source. Because Application Server
contains templates for many vendor JDBC implementations, the administrative console surfaces the
required properties and prompts you for them as you create a data source. However, if you script
your data access configurations, you must consult the article Data source minimum required settings,
by vendor, for the required properties and settings options.
- Optional: Configure custom properties.
Like the required properties, custom properties for specific vendor JDBC drivers must be set on
the application server data source. Consult your database documentation for information about
available custom properties. To configure a custom class to facilitate the handling of database
properties that are not recognized natively by the Application Server, refer to the topic,
Developing a custom DataStoreHelper class.
There are also optional data source properties, such as the DB2 sslConnection custom property,
that you might want to configure. Refer to the Application Programming Guide and Reference for Java for your version of DB2
for z/OS® if you use the DB2 Universal JDBC Driver provider for more information about these custom properties.
- Bind resource references to the data source. See the article, Data source lookups for
enterprise beans and web modules.
- Test the connection (for non-container-managed persistence usage).
See the
topic, Test connection service.
Results
If you use the DB2 JDBC Universal Driver, you might
experience data source failures that the application server JVM log does not document. Check the DB2 database log or the WebSphere Application Server JDBC trace log (if JDBC trace was active). You might find that a
bad authentication credential is the cause of failure. Currently, the DB2 JDBC Universal Driver does not identify or surface the errors that are
produced by non-valid authentication credentials in a proper or consistent way.Even if you
receive information about a bad credential, check the database and JDBC trace logs. These logs
provide more reliable, detailed error data on authentication failures.
Best practice: The JDBC trace log exists only if the JDBC trace service is active during
server start up. Activate the service in the administrative console. For more information, see the
topic, Enabling trace at server startup. Specify WAS.database as the trace group and select
com.ibm.ws.db2.logwriter as the trace string.