The aim of this wiki is to briefly analise and summarise Weblogic's ability to provide HTTP session replication between clusters.

Characteristics

• No primary/backup scenario, all clusters are considered active: global load balancer determines which cluster to send it to based on the current number of requests being handled by each cluster.
• Local load balancer deals with intra cluster load balancing.
• Sticky sessions a requirement.
• If cluster node fails, failover is attempted on a local cluster node and if all cluster nodes fail to respond, failover is done to other cluster.
• No proxy architechture for replication, all cluster nodes can use the dedicated replication channel when needed.

Limitations

• Inter cluster replication limited only to the HTTP session replication use case.
• Clusters must be identical, i.e. each cluster involved in cross cluster replication MUST have the same number of servers.

Two Use Cases

MAN HTTP Session State Replication

• To be used when clusters are close enough and network latency is not an issue.
• Synchronous in-memory session replication between clusters.
• Each server has a designated backup server (looks like this is statically defined in the global load balancer).
• If server fails in cluster, failover is done to another server in same cluster and this server communicates with the original backup (in the other cluster) to retrieve the session.
• If backup server fails, primary servers selects automatically a new backup server. Dunno based on which parameters.
• If communications between clusters fails, servers choose a new backup server in the local cluster. Once communication is reestablished, backup in remote cluster is used.

WAN HTTP Session State Replication

• To be used when clusters are far apart and network latency is noticeable.
• No in-memory replication but instead sessions are stored in database.
• Asynchronous session replication after request retrieving session state from database. On the designated backup node, replicated session is stored in database too.
• If entire cluster fails, failover is done to other cluster and requests continue to be process with last known state in database.
• If server fails in cluster, failover is done to designated backup in other cluster and a new secondary will be chosen to be backup (docu is not clear about whether this new secondary is in the local cluster or in another cluster).