For access to relational databases, applications use the
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 IBM Optim pureQuery Runtime, see
the documentation about configuring JDBC providers to use IBM Optim
pureQuery Runtime to access DB2.
Determine the version of
data source that you need according to the API specification of your
applications.
- Data sources (WebSphere® Application Server
Version 4) are for use with the Enterprise JavaBeans (EJB) 1.0 specification and the Java Servlet 2.2 specification.
- Data sources of the latest standard version are for use with applications
that implement the more advanced releases of these specifications.
Important: If
you connect to DB2 for z/OS
® through the JDBC Universal
JDBC Driver, follow the steps that are outlined in the topic, Using
the DB2 Universal JDBC Driver to access DB2 for z/OS. This article
gives detailed instruction on installing the JDBC driver and related
files, plus activating required JDBC properties.
- Create a JDBC provider.
When you create
a JDBC provider from the administrative console, see the topic, Configuring
a JDBC provider using the administrative console.
OR
Using the wsadmin scripting client, see the topic, Configuring
a JDBC provider using the scripting.
OR
Using
the Java Management Extensions (JMX) API, see the
topic, Creating a JDBC provider and data source using the JavaManagement Extensions API.
- Create a data source.
From the administrative
console, see the topic, Creating a data source using the administrative
console.
OR
Using the wsadmin scripting client,
see the topic, Configuring new data sources using scripting. For V4
data sources, see the topic, Configuring new WAS40 data sources using
scripting.
OR
Using the JMX API, see the topic,
Creating a JDBC provider and data source 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.
bprac