Clusters and Replicated Persistence

Setting the persistence type to replicated enables WebLogic to replicate the session state in memory itself. Like the default memory persistence scheme, session data is stored in memory. Unlike the default memory persistence, this scheme works closely with the notion of primary and secondary servers in the cluster, as discussed later in Chapter 14. WebLogic creates the primary session state on the server that a client first connects to, and then transparently replicates the session-state information onto a secondary server instance. The process of copying session state from one server instance to another in the cluster is called in-memory replication. The replica is kept up-to-date so that the secondary server can take over when the original server instance that holds the session data fails.

In-memory session-state replication will work only for those object-valued attributes in the session that are Serializable objects. Changes to the session object will be replicated only if you use the setAttribute( ) and removeAttribute( ) methods on the HttpSession object. These methods ensure that any changes to the attributes of the session are mirrored onto the secondary server for the client. Remember that only nontransient attributes of an object in the session will be replicated to the secondary server. All transient attributes of the object will be ignored.

If you modify the state of an object stored in the session using another object reference, ...

Get WebLogic: The Definitive Guide now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.