Clustering and JDBC Connections

WebLogic Server supports clustered JDBC, which means that some of the JDBC objects are aware of the cluster and will behave differently in a cluster. For instance, a connection pool is not cluster-aware. Assigning a connection pool to a cluster is equivalent to assigning it individually to each server in the cluster, and thus, there is no change in its behavior. A data source, on the other hand, is cluster-aware. If you assign a data source to a cluster, it behaves differently from a data source that is targeted to each member of the cluster individually. In this case, it can distribute connection requests across all copies of the pool assigned to the different members of the cluster. A data source internally uses WebLogic's RMI Driver to obtain a connection from the pool. The RMI Driver then directs the connection request to a pool on one of the clustered servers. The client is then "pinned" to that server for the duration of the database transaction, and until the connection is released.

Now, if we consider a data source that is targeted to a cluster, and each Managed Server in the cluster has a JDBC pool associated with the data source, WebLogic ensures the JDBC requests to the data source are handled uniformly by all members of the cluster. When an external client requests a connection from a data source assigned to the cluster, it obtains a replica-aware stub for the data source. The replica-aware stub maintains a list of all active servers in the cluster that host the particular data source. The clustered stub encapsulates the load-balancing logic and can distribute the connection requests evenly across the Managed Servers in the cluster. Because a data source is cluster-aware, if one of the Managed Servers fails, the client can make another connection request, which then will be handled by any one of the remaining members of the cluster.

A cluster-aware data source, however, behaves differently for local connection requests. If a server-side application (such as a servlet, EJB, etc.) running on one of the Managed Servers in a cluster requests a connection from a cluster-aware data source targeted to that same cluster, the connection is returned from the local JDBC pool on the same server, and not from any other member of the cluster. So, a server-side request for a JDBC connection from a clustered data source always will resolve to the local connection pool (or multipool) assigned to it, and never to a remote connection pool on another cluster server. The connection is then "pinned" to the local server for the duration of the database transaction, and until the connection is released.

5.5.1 Failover and Load Balancing

By default, WebLogic doesn't support connection failover. If a server instance dies, all active JDBC connections are killed, all active transactions are aborted and rolled back, and all JDBC objects associated with the dead connections become invalid. However, clustered JDBC does enable a client to reconnect when an existing connection fails. The cluster-aware nature of data sources allows an external client to request another connection when the Managed Server that held the original JDBC connection dies. A server-side application, on the other hand, fails to reconnect to the database when its local connection pool dies because a cluster-aware data source always resolves to the local pool. If you need failover for server-side applications, use a multipool configured for high availability. Only then can WebLogic fail over to another connection pool if the existing pool fails.

If you have replicated, synchronized database instances, you can achieve database failover using a multipool operating in high-availability mode. The multipool would be configured with several connection pools, each pointing to different instances of the same database. In high-availability mode, WebLogic continues to return connections from the first pool in the list, until it fails for some reason. Only then does WebLogic try to obtain a connection from the next pool in the list. If the multipool directs a connection request to a connection pool that has reached maximum capacity and an available connection can't be obtained within the configured wait period, a PoolLimitSQLException is generated. It does not mean that the connection request is forwarded automatically to the next pool in the multipool. The only way to resolve this issue is to either increase the capacity of the connection pool, or increase the wait period.

A multipool operating in high-availability mode can support connection failover only if the TestConnectionsOnReserve attribute has been enabled for the connection pools. It uses the test to determine whether it has a bad connection; if so, it fails over to the next pool in the multipool.

A cluster-aware data source provides limited support for balancing the load of connection requests from external clients. This is because the replica-aware stub simply distributes the connection requests evenly across the members of the cluster. It does not react to the current load of the connection pools. For instance, a connection request to a clustered data source still could be redirected to a Managed Server where the connection pool has reached maximum capacity and all connections are busy.

On the other hand, you could use a multipool to balance the load of JDBC connections over its ordered list of connection pools. In this case, you assign the multipool to the cluster and the connection pools to all Managed Servers, and use a data source to tap into the multipool. In a load-balancing multipool, the connection pools are accessed in a round-robin scheme. For each successive client request, the list is rotated so that the next pool can be tapped.