Manage HTTP Session States : Session Replication

Configuring a Web Application for In-Memory Replication

Overview

Using the in-memory replication, WebLogic Server copies a session state from one server instance to another. The primary server creates a primary session state on the server to which the client first connects, and a secondary replica on another WebLogic Server instance in the cluster. The replica is kept up-to-date so that it may be used if the server that hosts the Web application fails.

When a client attaches to a server in the cluster and creates a primary session state, the server hosting the primary state ranks other servers in the cluster to determine which server should host the secondary. Server ranks are assigned using a combination of the server’s location (whether or not it resides on the same machine as the primary server) and its participation in the primary server’s preferred replication group.

With persistent JDBC replication, a database is configured for the storage of session objects.  After it is configured, each of the server instances in a cluster uses an identical JDBC data source to share access to the database. This technique provides for good failover capability because any server in the cluster will be able to resolve a client’s request; however, there is a significant performance reduction.

Assigning Preferred Replication Boundaries

Perform the following steps:

1.	If not already running, start Apache and the WebLogic administration server.
2.	Launch the administration console. Click Lock & Edit in the Change Center panel. Then select Environment > Servers from the Domain Structure panel.
3.	Select one of your clustered managed servers:
4.	Click the Configuration > Cluster tab:
5.	Enter the following values: Field Value Replication Group dizzyRepGroup1 Preferred Secondary Group dizzyRepGroup2 Click the Save button.
6.	Repeat the previous steps to configure the same Replication Group and Preferred Secondary Group for the second managed server in the cluster.
7.	Repeat the previous steps to configure the opposite Replication Group and Preferred Secondary Group settings for the final managed server in the cluster: Field Value Replication Group dizzyRepGroup2 Preferred Secondary Group dizzyRepGroup1
8.	Click Activate Changes in the Change Center panel. Start your clustered managed servers.

Configuring a Web Application for In-Memory Replication

Perform the following steps:

1.	Download the shoppingcart.zip file that contains the sample Web application shoppingcart.war file.
2.	Extract shoppingcart.war to a folder named shoppingcart using any archive utility, such as jar: > mkdir shoppingcart > cd shoppingcart  > jar xf ../shoppingcart.war
3.	Edit the shoppingcart/WEB-INF/weblogic.xml file.
4.	After the supplied comment, add the following: <session-descriptor>   <persistent-store-type>replicated_if_clustered</persistent-store-type> </session-descriptor>
5.	Re-create shoppingcart.war by using any archive utility. For example: > cd shoppingcart > rm ../shoppingcart.war > jar cf ../shoppingcart.war *
6.	Use the administration console to install and start shoppingcart.war. Target the application to your cluster: Tip: Remember that you need to Activate your changes after installing a new application.

Testing In-Memory Replication

Perform the following steps:

1.	Direct your Web browser to the shopping cart application, but through the Apache Web server. For example, if Apache is running on port 80, use http://localhost/shoppingcart:

2.	Click the Go Shopping link. Use the Add to Shopping Cart links to add an item to your cart. Then click Back to Home Page.
3.	Repeat the previous step to add a second item to your cart. Then click the View Shopping Cart link.
4.	Inspect the command shells used to start your managed servers. Determine which server the user's session is pinned to: "added new element: package of 5 legal pads" "Your shopping cart includes:         Item: box of 12 pens (black) price: 4.99         Item: package of 5 legal pads price: 15.99"
5.	Kill the server hosting the user's session.
6.	Use the application to view your shopping cart again, and confirm that its contents are still the same.
7.	Once again, use the server shells to determine which server the user failed over to (the secondary). Does the selected secondary make sense, given your machine and replication group definitions?
8.	Restart the server that was killed. Close your Web browser.