File Synchronization in clustered environment

In the clustered environment whenever you want to make any configuration changes your supposed to use WAS Admin Console and make those changes on the Deployment Manager, the deployment manager then takes care of Synchronizing those changes to all the nodes.

Please remember one important thing that the Deployment Manager will only synchronize changes under the config directory


In case of portal server there portal configuration service related files stored under PortalServer directory. So if you want to make any changes in these files you should always use WAS Admin Console. Those changes would get stored in resources.xml file under corresponding scope.

Similarly if you make any changes in wkplc.properties or wkplc_comp.properties or wkplc_dbtype.properties file you will have to copy those changes manually. Please note one more important thing that even in a cluster the wkplc.properties file will be specific to a server so you cannot copy it as it is to other machine. Instead you should copy the corresponding helper file from primary portal node and use it only copy necessary property values to the other nodes.

Managing replication in your cluster

Replication is a service provided by WAS that transfers data, objects or events among application servers. Data replication can be used to make data for session managerm dynamic cache and stateful session beans available across many application servers in cluster

• 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 WebSphere Portal can make use of 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 absolutely necessary to maintain data integrity between multiple 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.


• Distributed sessions: 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 case of 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 WebSphere Portal cluster. Distributed session support is not enabled by default, so you will have to determine whether to provide this capability in your cluster, and, if so, which of the two techniques you will use: memory-to-memory session replication and database session persistence.