WebLogic Session Replication – In Memory (12C)
WebLogic supports different types of Session Replication. They are In-memory, File based and JDBC bases session replications. This section, we walk through about In-Memory based Session replication. Here the session is saved in Memory; that is RAM. When a session is established in the deployed application, WebLogic copies the session state from active server to another server in the same cluster so if the server loaded fully or failover occurs then the other server will take care of the client.
We need to create two replication group in the cluster. One is Primary, and the other is Secondary. WebLogic determines which server the session should be copied over is called the ranking factor. The ranking factor is determined by
1. Where the WebLogic ‘Machine’ are located
2. Primary or Secondary Replication Group
This section is a continuation of WebLogic Clustering and Load Balancing. If you interested to see the instruction of those please click on the following links
Assume, we have the cluster configured in WebLogic with two managed servers as like below.
WebLogic Session Replication – Example started
1. Login into WebLogic console
2. Click on the Server under Environment and stop all the managed servers in the cluster. Click on the server 1 (here it is new_managedServer1)
3. Select the Cluster tab; Input the following data to it and click the button Save
Replication Group: RepGroup1
Preferred Secondary Group: RepGroup2
4. GO back to the server’s tab and select the second server.
5. Click on the cluster tab and input the following value. Click on the button Save.
Replication Group: RepGroup2
Preferred Secondary Group: RepGroup1
That’s it. The WebLogic session replication via In Memory is done at WebLogic.
Specify Session Replication in WebLogic.XML file
In your web application, Create a webLogic.xml under the WEB-INF directory. Add the following element in the file
<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 9.1//EN" "http://www.bea.com/servers/wls810/dtd/weblogic
The WebLogic Session Replication is done. You can skip the below section if you don’t want to. The below section walks through on testing the Session Replication by deploying a web application.
Test the Session Replication
Download the sample web application sessionreplicationwebapp. It has the login page and welcome page. The login page creates a valid HTTP session on successful login and redirects to the welcome page. Here we deploy this web application on the clustered instance and do test by following steps .
1.Deploy the web application in cluster
2. Open the web app in in server1 and do login
2. The web app creates a session and displays the welcome page with Session ID
3. Open the welcome page on server2 and note the Session ID is same.
Click on the Deployment. Click Install
Unzip the downloaded file. Select the War file from the unzipped folder and Click next
Select the Cluster
Open the application with the First server. It asks for login (admin/admin)
The session will get created, and you it will redirect to weblomd page. Note the session id
Open the Welcome page URL in second server (http://localhost:7004), You will get the same session ID
That’s it , we are done with Session Replication.
How to handle failover for a pinned service in WebLogic. Pinned Services, such as JMS, JTA are designed to deploy into only one active server in a cluster. What happens if the active server shots down? In my next posthttp://www.catgovind.com/weblogic/how-to-setup-jms-as-a-migratable-service-with-in-a-weblogic-cluster-12c/I covered how to setup and handle failover for a Pinned service ( JMS) in WebLogic and
The views expressed on this blog are my personal views and do not necessarily reflect the views of my employer.
Please feeling free to reach me on any comments and feedbacks you have. Would be more than glad to listen and reply 🙂