Transactional Collocation Optimization for Collocated Objects

5-10 Using Clusters for Oracle WebLogic Server Figure 5–4 Collocation Optimization Overrides Load Balancer Logic for Method Call In this example, a client connects to a servlet hosted by the first WebLogic Server instance in the cluster. In response to client activity, the servlet obtains a replica-aware stub for Object A. Because a replica of Object A is also available on the same server instance, the object is said to be collocated with the clients stub. WebLogic Server always uses the local, collocated copy of Object A, rather than distributing the clients calls to other replicas of Object A in the cluster. It is more efficient to use the local copy, because doing so avoids the network overhead of establishing peer connections to other servers in the cluster. This optimization is often overlooked when planning WebLogic Server clusters. The collocation optimization is also frequently confusing for administrators or developers who expect or require load balancing on each method call. If your Web application is deployed to a single cluster, the collocation optimization overrides any load balancing logic inherent in the replica-aware stub. If you require load balancing on each method call to a clustered object, see Section 9.3, Recommended Multi-Tier Architecture, for information about how to plan your WebLogic Server cluster accordingly.

5.2.6.1 Transactional Collocation

As an extension to the basic collocation strategy, WebLogic Server attempts to use collocated clustered objects that are enlisted as part of the same transaction. When a client creates a UserTransaction object, WebLogic Server attempts to use object replicas that are collocated with the transaction. This optimization is depicted in the example shown in Figure 5–5 . Load Balancing in a Cluster 5-11 Figure 5–5 Collocation Optimization Extends to Other Objects in Transaction In this example, a client attaches to the first WebLogic Server instance in the cluster and obtains a UserTransaction object. After beginning a new transaction, the client looks up Objects A and B to do the work of the transaction. In this situation WebLogic Server always attempts to use replicas of A and B that reside on the same server as the UserTransaction object, regardless of the load balancing strategies in the stubs for A and B. This transactional collocation strategy is even more important than the basic optimization described in Section 5.2.6, Optimization for Collocated Objects. If remote replicas of A and B were used, added network overhead would be incurred for the duration of the transaction, because the peer connections for A and B would be locked until the transaction committed. Furthermore, WebLogic Server would need to employ a multi-tiered JDBC connection to commit the transaction, incurring additional network overhead. By using collocating clustered objects during a transaction, WebLogic Server reduces the network load for accessing the individual objects. The server also can make use of a single-tiered JDBC connection, rather than a multi-tiered connection, to do the work of the transaction.

5.3 Load Balancing for JMS

WebLogic Server JMS supports server affinity for distributed JMS destinations and client connections. By default, a WebLogic Server cluster uses the round-robin method to load balance objects. To use a load balancing algorithm that provides server affinity for JMS objects, you must configure the desired method for the cluster as a whole. You can configure the load balancing algorithm by using the Administration Console to set weblogic.cluster.defaultLoadAlgorithm. For instructions, see Section 10.2.5, Configure Load Balancing Method for EJBs and RMIs.