Oracle® Application Server 10g Migrating From WebLogic
10g Release 3 (10.1.3) B16027-01 |
|
![]() Previous |
![]() Next |
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:
Migrating applications deployed on WebLogic Server that use JDBC, specifically WebLogic JDBC drivers, to OC4J and Oracle JDBC drivers can be straightforward, requiring little or no code changes to the applications migrated. 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.
WebLogic Server 8.1 supports J2EE 1.3 (JDBC 2.0) and OC4J supports J2EE 1.4 (JDBC 2.1). 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 should be minimal, often differing primarily in the area of proprietary extensions. Before analyzing any differences, an overview of JDBC Drivers is apt.
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:
Type 1, JDBC-ODBC Bridge—Translates calls into ODBC API calls.
Type 2, Native-API Driver—Translates calls into database native API calls. As this driver uses native APIs, it is vendor dependent. The driver consists of two parts: a Java language part that performs the translation, and a set of native API libraries.
Type 3, Net-Protocol—Translates calls into DBMS-independent network protocol calls. The database server interprets these network protocol calls into specific DBMS operations.
Type 4, Native-Protocol—Translates calls into DBMS native network protocol calls. The database server converts these calls into DBMS operations.
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.
WebLogic jDriver for Oracle—The WebLogic jDriver for Oracle provides connectivity to the Oracle database and requires an Oracle client installation since it is based on OCI (Oracle Call Interface API). The WebLogic jDriver for Oracle XA driver extends the WebLogic jDriver for Oracle for distributed transactions.
The Oracle thick or JDBC OCI driver is the equivalent of WebLogic jDriver for Oracle as well as WebLogic jDriver for Oracle XA since the JDBC OCI driver provides XA functionality.
WebLogic Pool Driver—The WebLogic Pool driver enables utilization of connection pools from server-side applications such as HTTP servlets or EJBs.
Oracle JDBC-OCI Driver—The Oracle JDBC-OCI driver allows J2EE applications to use connection pools. This driver supports JDBC 2.0 connection pool features fully.
WebLogic RMI Driver—The WebLogic RMI driver is a multitier, Type 3, Java Data Base Connectivity (JDBC) driver that runs in WebLogic Server and can be used with any two-tier JDBC driver to provide database access. Additionally, when configured in a cluster of WebLogic Servers, the WebLogic RMI driver can be used for clustered JDBC, allowing JDBC clients the benefits of load balancing and fail over provided by WebLogic Clusters.
WebLogic JTS Driver—The WebLogic JTS driver is a multitier, Type 3, JDBC driver used in distributed transactions across multiple servers with one database instance. The JTS driver is more efficient than the WebLogic jDriver for Oracle XA driver when working with only one database instance because it avoids two-phase commit.
Oracle Thin Driver—The two-tier Oracle Thin Type 4 driver provides connectivity from WebLogic Server to Oracle DBMS.
If you are already using the Oracle OCI or Oracle thin JDBC drivers from your WebLogic Server, your code will not require any changes and you can move to the section on configuring data-sources in OC4J.
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.
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.
For Oracle Application Server, you configure data sources using the Application Server Control Console 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 Console. 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 name of the data source. |
|
Class name of the JDBC. |
|
Number of seconds to wait before retrying a failed connection. Default value is 1 second. |
|
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 |
|
Number of seconds unused connections should be cached before being closed. |
|
JNDI path for binding this data source. |
|
Number of times to retry a failed connection. Default is 3 times. |
|
Maximum number of open connections for pooling data sources. |
|
Minimum number of open connections for pooling data sources. The default is zero. |
|
Displayed name of the data source. |
|
User password for accessing the data source (optional). |
|
JNDI path for binding a pooled version of this data source. This parameter only applies to a Relative or absolute path to a database-schema file for the database connection. |
|
Underlying data source of this specialized data source. |
|
JDBC URL for this data source (used by some data sources that deal with |
|
User name for accessing the data source (optional). |
|
Number of seconds to wait for a free connection if all connections are used. Default is 60. |
|
JNDI path for binding a transactional version of this data source. This parameter only applies to a |
|
Underlying |
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.
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 reused 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:
Reducing the load on the middle tier and server
Minimizing resource usage by session create and session close operations
Eliminating bottlenecks caused by socket and file descriptor limitations and 'n' user license limitations.
The JDBC 2.0 specification allows you to define a pool of JDBC database connections with the following objectives:
Maximize the availability of connections to resources.
Minimize the idle connections in the pool.
Return orphan connections to the pool and make them available for reuse by other servlets or application servers.
To meet these objectives, you:
Set the maximum connection pool size property equal to the maximum number of concurrently active user requests expected.
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 reuse is maximized and connection creation overhead minimized. You can also use connection pooling to control the number of concurrent database connections.
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 standalone 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.
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.
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 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.