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.