Skip Headers

Oracle Application Server 10g Migrating from WebLogic
10g (9.0.4)

Part Number B10425-01
Go To Documentation Library
Home
Go To Table Of Contents
Contents
Go To Index
Index

Go to previous page Go to next page

6
Migrating JDBC

This chapter provides the information you need to migrate database access code from WebLogic Server to Oracle Application Server. It addresses the migration of JDBC drivers, data sources, and connection pooling.

This chapter contains these topics:

Introduction

Migrating applications deployed on WebLogic Server that use JDBC, specifically WebLogic JDBC drivers, to OC4J and Oracle JDBC drivers is can be straightforward, requiring little or no code changes to the applications migrated. Both application servers support the same API levels for the JDBC API - full support for version 2.0 of the specification. All applications written to the standard JDBC specifications will work correctly and require minimal migration effort. The primary effort goes into configuring and deploying the applications in the new environment. Only in cases where proprietary extensions are used will the migration effort get complex.

Differences between WebLogic and Oracle Application Server Database Access Implementations

Both WebLogic Server and OC4J have fully J2EE 1.3 compliant containers that permit the usage of all types of JDBC drivers to access several different databases. Further, the JDBC drivers from BEA as well as Oracle support the same version of the JDBC standard - version 2.0 specifications. Therefore, the differences between the two servers are minimal, often differing primarily in the area of proprietary extensions. Before analyzing any differences, an overview of JDBC Drivers is apt.

Overview of JDBC Drivers

JDBC defines standard API calls to a specified JDBC driver, a piece of software that performs the actual data interface commands. The driver is considered the lower level JDBC API. The interfaces to the driver are database client calls, or database network protocol commands that are serviced by a database server.

Depending on the interface type, there are four types of JDBC drivers that translate JDBC API calls:

BEA provides a variety of options for database access using the JDBC API specification. These options include WebLogic jDrivers for the Oracle, Microsoft SQL Server, and Informix database management systems (DBMS). In addition to the Type 2 WebLogic jDriver for Oracle, WebLogic provides a Type 2 driver for Oracle XA and three Type 3 drivers - RMI Driver, Pool Driver and JTS.

Similarly, Oracle Application Server provides a variety of options for database access, particularly the best JDBC drivers for the Oracle database, and JDBC drivers from partner Merant for accessing several other databases including DB2.

Migrating Data Sources

The JDBC 2.0 specification introduced the java.sql.Datasource class to make the JDBC program 100% portable. In this version, the vendor-specific connection URL and machine and port dependencies were removed. This version also discourages using java.sql.DriverManager, Driver, and DriverPropertyInfo classes. The data source facility provides a complete replacement for the previous JDBC DriverManager facility. Instead of explicitly loading the driver manager classes into the client applications runtime, the centralized JNDI service lookup obtains the java.sql.Datasource object. The Datasource object can also be used to connect to the database. According to the JDBC 2.0 API specification, a data source is registered under the JDBC subcontext or one of its child contexts. The JDBC context itself is registered under the root context. A DataSource object is a connection factory to a data source.

WebLogic and OC4J both support the JDBC 2.0 data source API. A J2EE server implicitly loads the driver based on the JDBC driver configuration, so no client-specific code is needed to load the driver. The JNDI (Java Naming and Directory Interface) tree provides the DataSource object reference.

Data Source Import Statements

DataSource objects, along with JNDI, provide access to connection pools for database connectivity. Each data source requires a separate DataSource object, which may be implemented as a DataSource class that supports either connection pooling or distributed transactions.

To use the DataSource objects, import the following classes in your client code:

import java.sql.*;
import java.util.*;
import javax.naming.*;

In the case of WebLogic Server, you would use the weblogic.jdbc.* packages and in the case of OC4J, you would use oracle.jdbc.* packages.

Configuring Data Sources in the Application Server

For Oracle Application Server, you configure data sources using the Application Server Control web pages to specify the data source name, database name and JDBC URL string. You can also define multiple data sources to use a single connection pool, thereby allowing you to define both transaction and non-transaction-enabled DataSource objects that share the same database.

The best way to configure and define data sources is through Application Server Control. However, in this document we will examine the underlying infrastructure and focus on direct manipulation of the configuration files. OC4J uses flat files to configure data sources for all of its deployed applications. Data sources are specified in the <ORACLE_HOME>/j2ee/home/config/data-sources.xml file. Following is an sample data source configuration for an Oracle database. Each data source specified in data-sources.xml (xa-location, ejb-location and pooled-location) must be unique.

<data-source
class="com.evermind.sql.DriverManagerDataSource"
name="Oracle"
url="jdbc:oracle:thin@<database host name><database listener port 
number>:<database SID>"
pooled-location="jdbc/OraclePoolDS"
xa-location="jdbc/xa/OracleXADS"
ejb-location="jdbc/OracleDS"
connection-driver="oracle.jdbc.driver.OracleDriver"
username="scott"
password="tiger"
url="jdbc:oracle:thin@<database host name><database listener port 
number>:<database SID>"
schema="database-schemas/oracle.xml"
inactivity-timeout="30"
max-connections="20"
/>

Table 6-1 describes all of the configuration parameters in data-sources.xml. (Not all of the parameters are shown in the example above).

Table 6-1 Configuration Parameters in data-sources.xml File  
Parameter Description

class

Class name of the data source.

connection-driver

Class name of the JDBC.

connection-retry-interval

Number of seconds to wait before retrying a failed connection.

Default value is 1 second.

ejb-location

JNDI path for binding an EJB-aware, pooled version of this data source; this version will participate in container-managed transactions. This is the type of data source to use from within EJBs and similar objects.

This parameter only applies to a ConnectionDataSource.

inactivity-timeout

Number of seconds unused connections should be cached before being closed.

location

JNDI path for binding this data source.

max-connect-attempts

Number of times to retry a failed connection.

Default is 3 times.

max-connections

Maximum number of open connections for pooling data sources.

min-connections

Minimum number of open connections for pooling data sources.

The default is zero.

name

Displayed name of the data source.

password

User password for accessing the data source (optional).

pooled-location

JNDI path for binding a pooled version of this data source.

This parameter only applies to a ConnectionDataSource.

Relative or absolute path to a database-schema file for the database connection.

source-location

Underlying data source of this specialized data source.

url

JDBC URL for this data source (used by some data sources that

deal with java.sql.Connections.

username

User name for accessing the data source (optional).

wait-timeout

Number of seconds to wait for a free connection if all

connections are used. Default is 60.

xa-location

JNDI path for binding a transactional version of this data source.

This parameter only applies to a ConnectionDataSource.

xa-source-location

Underlying XADataSource of the specialized data source (used by OrionCMTDataSource).

Obtaining a Client Connection Using a Data Source Object

To obtain a connection from a JDBC client, you would use JNDI to look up and locate the DataSource object. This is illustrated in the following code fragment where you obtain a connection in WebLogic Server:

try
{
    java.util.Properties parms = new java.util.Properties();
    parms.setProperty(Context.INITIAL_CONTEXT_FACTORY,   
    "weblogic.jndi.WLInitialContextFactory");

    javax.naming.Context ctx = new javax.naming.InitialContext(parms);
    javax.sql.DataSource ds = (javax.sql.DataSource)ctx.lookup("jdbc/SampleDB");
    java.sql.Connection conn = ds.getConnection();

    // process the results
    ...
}

To migrate the above code from WebLogic Server to OC4J, you need to change the class that implements the initial context factory (Context.INITIAL_CONTEXT_FACTORY) of the JNDI tree from weblogic.jndi.WLInitialContextFactory, which is the WebLogic-specific class, to com.evermind.server.ApplicationClientInitialContextFactory, which is the OC4J specific class.

With this change, your code is ready for deployment on OC4J and to use the Oracle JDBC drivers.

Migrating Connection Pools

Most web-based resources, such as servlets and application servers, access information in a database. Each time a resource attempts to access a database, it must establish a connection to the database, consume system resources to create the connection, maintain it, and then release it when it is no longer in use. The resource overhead is particularly high for web-based applications, because of the frequency and volume of web users connecting and disconnecting. Often, more resources are consumed in connecting and disconnecting than in the interactions themselves.

Connection pooling enables you to control connection resource usage by spreading the connection overhead across many user requests. A connection pool is a cached set of connection objects that multiple clients can share when they need to access a database resource. The resources to create the connections in the pool are expended only once for a specified number of connections, which are left open and re-used by many client requests, instead of each client using resources to create its own connection and closing it after its database operation is complete. Connection pooling improves overall performance in the following ways:

The JDBC 2.0 specification allows you to define a pool of JDBC database connections with the following objectives:

To meet these objectives, you:

  1. Set the maximum connection pool size property equal to the maximum number of concurrently active user requests expected.

  2. Set the minimum connection pool size property equal to the minimum number of concurrently active user requests expected.

The connection pooling properties ensure that as the number of user requests decreases, connections are gradually removed from the pool. Likewise, as the number of user requests begins to grow, new connections are created. The balance of connections is maintained so that connection re-use is maximized and connection creation overhead minimized. You can also use connection pooling to control the number of concurrent database connections.

Overview of Connection Pools

Connection pools provide ready-to-use pools of connections to your DBMS. Since these database connections are already established when the connection pool starts up, the overhead of establishing database connections is eliminated. You can utilize connection pools from server-side applications such as HTTP servlets or EJBs using the pool driver or from stand-alone Java client applications.

One of the greatest advantages of connection pooling is that it saves valuable program execution time and has almost no or very low overhead. Making a DMBS connection is very slow. With connection pools, connections are established and available to users before they are needed. The alternative is for application code to make its own JDBC connections when needed. A DBMS runs faster with dedicated connections than if it has to handle incoming connection attempts at runtime.

How Connection Pools Enhance Performance

Establishing a JDBC connection with a DBMS can be very slow. If your application requires database connections that are repeatedly opened and closed, this can become a significant performance issue. WebLogic Server and Oracle Application Server connection pools offer an solution to this problem.

When WebLogic Server or Oracle Application Server starts, connections from the connection pools are opened and are available to all clients. When a client closes a connection from a connection pool, the connection is returned to the pool and becomes available for other clients; the connection itself is not closed. There is little cost to "open" and "close" pool connections.

How many connections should you create in the pool? A connection pool can grow and shrink according to configured parameters, between a minimum and a maximum number of connections. The best performance will always be when the connection pool has as many connections as there are concurrent users.

Overview of Clustered JDBC

Relevant only in multitier configurations, clustered JDBC allows external JDBC clients to reconnect and restart their JDBC connection without changing the connection parameters, in case a serving cluster member fails. For WebLogic, clustered JDBC requires data source objects and the WebLogic RMI driver to connect to the DBMS. Data source objects are defined for each WebLogic Server using the WebLogic Administration Console.

Oracle provides functionality that is similar to and more advanced than that provided by the clustered JDBC by leveraging the TAF capabilities of OCI.

Performance Tuning JDBC

Performance tuning your JDBC application in OC4J is similar to that for WebLogic Server. Connection pooling helps improve performance by avoiding the expensive operation of creating new database connections. The guidelines on writing efficient code hold true for Oracle Application Server and WebLogic Server.


Go to previous page Go to next page
Oracle
Copyright © 2003 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Table Of Contents
Contents
Go To Index
Index