Replicating HTTP Sessions across Data Centers

Introduction

As explained in a previous post, Coherence*Web is a great feature which allows you to store your HTTP sessions in a Coherence Cluster. Since Coherence introduced Federation in 12.2.1, it has been possible to federate the HTTP session stored in Coherence*Web. This allows applications to replicate HTTP Sessions across data centers, which can tackle scenarios where-in an entire data-center goes down.

The last post on Easier configuration of Federated Caches explained how easy it is to configure federation in a WebLogic Server (WLS) domain. This post will build on that and explain how to extend that approach to federate HTTP sessions as well.

Solution

The first 2 steps for using Federated HTTP session using Coherence*Web is same as explained in Step 1 and Step 2 under the Setup section. Once 2 WLS domains have been installed and configured to use Federation as explained in those steps, the following settings need to be carried out.

Enable Coherence*Web federated session storage

Navigate to the Coherence settings tab of the DataTier WLS Cluster and enable the “Coherence Web Federated Storage Enabled” check-box as shown below

oie_s3OC4PC0TbYL.png

Deploy a web application

Deploy a web application onto the ClientTier WLS cluster. There are 2 configurations required to enable Federated HTTP sessions. They are

Enable Coherence*Web in the web application. This is done by configuring Coherence*Web as the session persistence type in weblogic.xml file of the web application as shown below

weblogic_xml.png

Set the coherence-session-cache-federated context parameter in the web.xml of the web application, as shown below

cwebcontextparam.png

After making the above changes, deploy the web application and navigate to the URL of Site1. Add some entries in the HTTP session. Now use the same HTTP Session to connect to Site2 and validate that the changes done in Site 1 is available.

Using the same HTTP Session

HTTP Sessions are based on Cookies which are exchanged between the Browser and the Server. Once an HTTP session is created, server sends back a session cookie(JSESSIONID is the default cookie name in WebLogic) to the Browser. Browser sends the same cookie back to the server in the subsequent requests. Server validates the cookie that it receives i.e. it checks if the cookie being sent is an existing and valid cookie. In case of Coherence*Web, server checks if the session as provided in the cookie exists in the session cache.

Browser will send the cookie back in the subsequent requests only the host-name of the next request matches that of the previous request. In typical deployments, there will be a load-balancer which sits in front of the managed server of both sites, so that even if a Site goes down, the load-balancer will point the next HTTP requests to the site which is available. We will not cover that topic here, but in-turn suggest a simple way to simulate such a set-up.

Let us assume that host.site1.oracle.com is the hostname of the managed server on Site1 and it IP address is host-site1-ip-address. Similarly host-site2-ip-address will be the IP Address of Site2 managed server. In the hosts file(/etc/hosts in linux), add an entry as follows

host-site1-ip-address webapphost

and access the web application using a browser using “webapphost” as the hostname (Please switch off any proxies in the system for this browser session). Execute some actions in the web application such that the session has some data populated. Keep the browser session open and change the entry in the hosts file as below

host-site2-ip-address webapphost

Refresh the browser session(use ctrl + F5 so that browse refreshes the pages). The next request will go to the managed server of Site2, and the session details should still be available. For example, if the web application was a shopping cart application and you had added some entries in the shopping cart, the shopping cart must be the same when you access the managed server of Site2.

Example Web Application

The attached web application can be used as a sample application to test the set-up. The web application is already Coherence*Web federation enabled as explained above, and can be deployed to the ClientTier WLS clusters of Site1 and Site2 domains. You can use the same script provided in the previous blog if you want to generate such a set-up.

Once the web application is deployed, as explained in “Using the same HTTP Session” section above, make the necessary changes in the hosts file and open the following URL in the web application

http://webapphost:7007/shoppingcart/shopping.jsp

and add some entries in the cart. Change the hosts file to point to Site2 IP Address and then refresh the browser (use ctrl + F5 so that the page is refreshed properly) and navigate to the shopping cart. You should see the items that have been added in the first request, still part of the shopping cart.

JVisualVM

The Coherence JVisaulVM plugin can be used to monitor federation related metric as explained here. The Coherence*Web federated session cache can also be monitored using JVisualVM. Sample screenshot is shown below:

cweb-jvisualvm.png

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s