Version 3

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



    • 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.



    • 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).