Manage replication in the cluster
IBM WebSphere Application Server provides a replication service. This service transfers data, objects, or events among application servers. Data replication can be used to make data for session manager, dynamic cache, and stateful session beans available across many application servers in a cluster. Review the following information to manage replication:
Note: By default, the cluster scripts enable dynamic caching for each cluster member. The replication type is set to NOT SHARED.
- Dynamic caching
- Data replication service (DRS) is the internal WebSphere Application Server component that replicates data among application servers. There are several types of data replication, and HCL WebSphere Portal can use data replication for dynamic caching and for memory-to-memory replication of session data. Enabling data replication for dynamic caching in a cluster environment is necessary to maintain data integrity between multiple HCL WebSphere Portal nodes in the cluster. Replication also helps improve performance by generating data once and then replicating it to other servers in the cluster.
- AIX HP-UX Linux Solaris Windows : Dynamic cache service settings
DB2 for z/OS tip: If we use the IBM DB2 Universal Database for z/OS JDBC type 2 driver, we must set the JDBC driver custom property fullyMaterializeLobData to false. See Data sources for information.
- IBM i: Dynamic cache service settings
DB2 for z/OS tip: If we use the IBM DB2 Universal Database for z/OS JDBC type 2 driver, we must set the JDBC driver custom property fullyMaterializeLobData to false. See Data sources for information.
- z/OS : Dynamic cache service settingsDB2 for z/OS tip: If we use the IBM DB2 Universal Database for z/OS JDBC type 2 driver, we must set the JDBC driver custom property fullyMaterializeLobData to false. See Data sources for information.
- Distributed sessions
- HCL WebSphere Portal can use the WebSphere Application Server capabilities to support HTTP session failover, which enables one node in a cluster to access information from the existing HTTP session in a failure in the cluster node originally handling that session. This capability is referred to as distributed sessions. WebSphere Application Server provides two techniques that can be used for distributed sessions, either of which can be used in a HCL WebSphere Portal cluster. Distributed session support is not enabled by default, so we must determine whether to provide this capability in the cluster. And, if so, which of the two techniques we use: memory-to-memory session replication and database session persistence.Warning: The memory-to-memory session application can lead to low memory conditions if failures cause replication to fail. This condition can occur because the local and backup sessions are stored in the JVM memory. Therefore, failures with replicating the session data can prevent freeing the memory that is allocated for the backup session.
- AIX HP-UX Linux Solaris Windows :
- For general information, read Session management support.
- For memory-to-memory information, read Memory-to-memory replication.
- For database session information, read Configure for database session persistence.
- IBM i:
- For general information, read Session management support.
- For memory-to-memory information, read Memory-to-memory replication.
- For database session information, read Configure for database session persistence.
- z/OS :
- For general information, read Session management support.
- For memory-to-memory information, read Memory-to-memory replication.
- For database session information, read Configure for database session persistence.
- Manage Personalization cache replication in the cluster Enable the Personalization cache replication if we want to propagate invalidations in the Personalization caches to the other nodes in the cluster.