Failover and JDBC Connections Understanding Server and Service Migration

6-24 Using Clusters for Oracle WebLogic Server

6.3.4 Object Deployment Requirements

If you are programming EJBs to be used in a WebLogic Server cluster, read the instructions in this section to understand the capabilities of different EJB types in a cluster. Then ensure that you enable clustering in the EJBs deployment descriptor. See weblogic-ejb-jar.xml Deployment Descriptor Reference in Programming WebLogic Enterprise JavaBeans for Oracle WebLogic Server for information about the XML deployment elements relevant for clustering. If you are developing either EJBs or custom RMI objects, also refer to Using WebLogic JNDI in a Clustered Environment in Programming JNDI for Oracle WebLogic Server to understand the implications of binding clustered objects in the JNDI tree.

6.3.4.1 Other Failover Exceptions

Even if a clustered object is not idempotent, WebLogic Server performs automatic failover in the case of a ConnectException or MarshalException. Either of these exceptions indicates that the object could not have been modified, and therefore there is no danger of causing data inconsistency by failing over to another instance.

6.4 Failover and JDBC Connections

JDBC is a highly stateful client-DBMS protocol, in which the DBMS connection and transactional state are tied directly to the socket between the DBMS process and the client driver. For this reason, failover of a connection is not supported. If a WebLogic Server instance dies, any JDBC connections that it managed will die, and the DBMSs will roll back any transactions that were under way. Any applications affected will have to restart their current transactions from the beginning. All JDBC objects associated with dead connections will also be defunct. Clustered JDBC eases the reconnection process: the cluster-aware nature of WebLogic data sources in external client applications allow a client to request another connection from them if the server instance that was hosting the previous connection fails. If you have replicated, synchronized database instances, you can use a JDBC multi data source to support database failover. In such an environment, if a client cannot obtain a connection from one data source in the multi data source because the data source doesnt exist or because database connectivity from the data source is down, WebLogic Server will attempt to obtain a connection from the next data source in the list of data sources. For instructions on clustering JDBC objects, see Section 10.2.12, Configure Clustered JDBC. Note: Any data source assigned to a multi data source must be configured to test its connections at reserve time. This is the only way a pool can verify it has a good connection, and the only way a multi data source can know when to fail over to the next pool on its list. 7 Whole Server Migration 7-1 7 Whole Server Migration The following sections describe the different migration mechanisms supported by WebLogic Server: ■ Section 7.1, Understanding Server and Service Migration ■ Section 7.2, Migration Terminology ■ Section 7.3, Leasing ■ Section 7.4, Automatic Whole Server Migration These sections focus on whole server-level migration, where a migratable server instance, and all of its services, is migrated to a different physical machine upon failure. WebLogic Server also supports service-level migration, as well as replication and failover at the application level. For more information, see Chapter 8, Service Migration and Chapter 6, Failover and Replication in a Cluster.

7.1 Understanding Server and Service Migration

In a WebLogic Server cluster, most services are deployed homogeneously on all server instances in the cluster, enabling transparent failover from one server to another. In contrast, pinned services such as JMS and the JTA transaction recovery system are targeted at individual server instances within a cluster—for these services, WebLogic Server supports failure recovery with migration, as opposed to failover. Migration in WebLogic Server is the process of moving a clustered WebLogic Server instance or a component running on a clustered instance elsewhere in the event of failure. In the case of whole server migration, the server instance is migrated to a different physical machine upon failure. In the case of service-level migration, the services are moved to a different server instance within the cluster. See Chapter 8, Service Migration. WebLogic Server provides this feature for making JMS and the JTA transaction system highly available: migratable servers. Migratable servers provide for both automatic and manual migration at the server-level, rather than the service level. When a migratable server becomes unavailable for any reason, for example, if it hangs, loses network connectivity, or its host machine fails—migration is automatic. Upon failure, a migratable server is automatically restarted on the same machine if possible. If the migratable server cannot be restarted on the machine where it failed, it is Note: Whole server migration is not supported on all platforms. See Support for Server Migration in Oracle WebLogic Server, WebLogic Portal and WebLogic Integration 10gR3 10.3. 7-2 Using Clusters for Oracle WebLogic Server migrated to another machine. In addition, an administrator can manually initiate migration of a server instance.

7.2 Migration Terminology