Overview of JDBC Resources

In order to enable a JDBC application to obtain a connection to a database, you need to install a two-tier JDBC driver on WebLogic Server. Only then can you use the JDBC driver to configure a connection pool on the server. This pool of reusable database connections then is available to all server-side applications and to any remote clients of WebLogic. Typically, a JDBC application will access the connection pool through a data source associated with the pool. A multipool provides additional load-balancing and failover capabilities over a number of connection pools. Let's take a closer look at these JDBC resources.

5.1.1 JDBC Drivers for WebLogic Server

A JDBC driver provides the actual connectivity to a vendor's DBMS product, as well as provides the implementation of the standard JDBC interfaces and classes. WebLogic supports two kinds of JDBC drivers:

Two-tier drivers

These JDBC drivers provide vendor-specific database access to WebLogic Server and the applications running on it. You can use a two-tier JDBC driver to configure a pool of reusable connections to the underlying database. Two-tier drivers include the JDBC drivers for Oracle, Sybase, and Microsoft shipped with WebLogic and third-party drivers such as the Oracle Thin Driver, Microsoft SQL Server 2000 JDBC driver, Sybase jConnect Driver, or the IBM JDBC drivers for Informix and DB2. A two-tier driver typically will provide native support for distributed transactions (WebLogic's jDriver for Oracle XA, Microsoft SQL Server 2000 JDBC driver, etc.).

Wrapper drivers

WebLogic is equipped internally with wrapper drivers (also called multi-tier drivers) that provide vendor-neutral access to a pool of database connections already configured for the server. They wrap the connection pools created by the two-tier drivers, providing different ways of accessing the pools. WebLogic supports three wrapper JDBC drivers, which we describe in the list shown next.

The Pool Driver

Server-side components (servlets, EJBs, etc.) can use this driver to acquire database connections directly from a connection pool.

The JTS Driver

Server-side applications can use this driver to obtain database connections from a connection pool that also can participate in distributed transactions.

The RMI Driver

Client (and server) JDBC applications can use this Type 3 JDBC driver to remotely access server-side connection pools via their data sources. The RMI Driver replaces the functionality of both the Pool Driver and JTS Driver.

A data source internally uses WebLogic's RMI Driver. When a remote client looks up the name of a data source in the JNDI tree in order to access the pool, it transparently uses the wrapper driver to dip into the connection pool. Because by default a data source is configured to honor distributed transactions, the RMI Driver ensures that the connections returned from the pool also can participate in distributed transactions.

Later, we examine how WebLogic's RMI Driver provides transparent access to connection pools that may be targeted to multiple server instances.

5.1.2 Connection Pools

JDBC connections are valuable resources because creating a connection to the database often can be a costly operation. For this reason, WebLogic lets you prepare a pool of reusable database connections, where each member of the pool has the same connection properties. Each connection in the pool connects to the same database server instance and uses the same database. All connections in the pool are associated with the same database user i.e., the same username and password is used to create the connections. WebLogic is responsible for maintaining this pool of physical connections, which is in fact a collection of PooledConnection objects. When a program requests a connection from the pool, it obtains a Connection object that represents a logical connection to the database. Behind the scenes, WebLogic dips into the pool and associates a physical connection with the logical connection. So, the client's Connection object is a handle to the actual PooledConnection object.

If there are no available connections in the pool when a connection is requested, WebLogic increases the size of the pool by creating new physical connections. When the pool reaches its maximum capacity and no connections are available, WebLogic can force the client to wait for an available connection. If a connection still doesn't become available, WebLogic simply returns a connection failure. Once the client has completed its database access and invoked the close( ) method on the logical Connection object, the actual PooledConnection object is returned back to the pool.

A connection pool greatly enhances the performance and scalability of enterprise applications because the same physical connection can be shared by multiple applications, including servlets, EJBs, JMS message consumers, and even ordinary Java clients. Here are some of the important benefits of a connection pool:

• Applications can avoid the costly overhead of repeatedly creating connections at runtime. Even the DBMS performs better when it needs only to deal with a dedicated pool of prepared connections, instead of responding to random connection requests from the client.
• The database connection properties used to define a connection pool are shared by all members of the pool. A client can simply dip into the connection pool without having to hardwire the actual connection attributes within its code.
• A connection pool enables you to better manage the number of concurrent database users because all the connections share the same user credentials. This is crucial if you have a DBMS license that imposes certain constraints, such as a limit on the number of licensed database users or a limit on the number of concurrent users.

Connection pools also are needed by other WebLogic services such as CMP entity beans and durable JMS messages, where WebLogic needs access to a set of JDBC connections to the underlying database. Later in this chapter we shall see how you can access a server-side JDBC pool using either a data source or one of WebLogic's wrapper JDBC drivers.

5.1.3 Multipools

WebLogic also lets you set up a multipool a pool of multiple connection pools that then can be targeted to either a single server or a cluster. A multipool defines a configurable algorithm for choosing a connection from one of the connection pools in the multipool. You can configure the multipool to operate in two modes:

High availability

If a connection pool fails, the database connection is picked from the next pool in the list. The next pool in the ordered list is examined only if there is a problem with the current pool. This could happen if the current pool is disabled or if the actual database becomes unavailable. Otherwise, the multipool continues to behave like any ordinary connection pool.

Load balancing

Connection requests are distributed evenly across the pools in a round-robin fashion.

Thus, you can set up the multipool so that either all connection pools evenly share the load of the connection requests, or a connection pool handles all the requests until it becomes inactive and then another "backup" pool is selected.

A multipool encapsulates access to multiple connection pools, where each connection pool is configured individually. All connections within a pool are configured to the same database, database user, and connection attributes. The attributes of the different pools in the multipool should vary in some significant way so that when one connection pool fails, the others are not also invalidated. You could even associate a different database user with each connection pool, if the DBMS has a limit on the number of simultaneous open connections per database user.

Typically, the JDBC pools within a multipool will point to distinct instances of the same database. If your DBMS configuration uses a high-availability solution (such as one based on data replication), you may use a multipool configured for high availability. If your DBMS configuration uses a number of servers running in parallel, and the database lives on shared, external (preferably fault-tolerant) storage, you may consider using a load-balancing multipool. However, if your DBMS runs on a single server or the DBMS automatically provides a single point of access to the cluster, as well as automatically handles failover, an ordinary connection pool will suffice.

It makes sense to configure multipools only if your application is independent of any specific connection pool. If each connection pool within the multipool points to a different database, multipools are useful provided your application does not depend on access to a particular database, or the databases are somehow kept in sync.

5.1.4 Data Sources

The DataSource interface is the preferred way for obtaining database connections. The data source allows you to map a logical name to a connection pool. An application then can access the connection pool directly by looking up the data source from the JNDI tree. The application need not be aware of the database setup or the actual connection properties. These settings are configured separately for the underlying connection pool. A server-side application can access a connection pool in several ways:

• You can use a data source that references the connection pool, or you can use a Pool Driver.
• If you need support for distributed transactions as well, you can use an XA-aware data source that references the connection pool, or you can use the JTS Driver.

Remember, the Pool and JTS Drivers are available only to server-side applications. We recommend that you look up the data source in the JNDI tree, and use it to access the connection pool. Later we shall see how you can use the Administration Console to set up the data source and its associated connection pool.