Manage HTTP Session States

Purpose

In this OBE tutorial, you test the HTTP session replication features of WebLogic Server against a supplied Java EE Web application. The first step in this process is to define replication groups by using the administration console. You then try both in-memory and JDBC replication by updating the XML deployment descriptors of the application. An active JDBC data source is necessary to use JDBC replication. You confirm successful HTTP session failover after bringing down the server that is hosting the current user's session.

Time to Complete

Approximately 45 minutes

Topics

This OBE tutorial covers the following topics:

	Overview
	System Requirements
	Assigning Preferred Replication Boundaries
	Configuring a Web Application for In-Memory Replication
	Testing In-Memory Replication
	Initializing a Database to Support JDBC Replication
	Targeting a JDBC Data Source to a Cluster
	Configuring a Web Application for JDBC Replication
	Testing JDBC Replication
	Summary
	Related information

Viewing Screenshots

Place the cursor over this icon to load and view all the screenshots for this tutorial. (Caution: Because this action loads all screenshots simultaneously, response time may be slow depending on your Internet connection.)

Alternatively, you can place the cursor over each individual icon in the following steps to load and view only the screenshot associated with that step.

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.

Back to Topic List

System Requirements

Make sure that your system environment meets the following requirements:

Software Requirements

Before starting this tutorial, first complete the following prerequisite tutorials:

Installing and Configuring Oracle WebLogic Server
Configuring Oracle WebLogic Server Managed Instances
Create a Basic Cluster
Configure Proxy Servers
Configure JDBC Data Sources

To complete the entire tutorial , you will need a running database of your choosing.

Minimum Hardware Requirements

Item	Specification
Processor Speed	1 GHz
Memory	2 GB
Free Hard Disk Space	1 GB

Back to Topic List

Assigning Preferred Replication Boundaries

Perform the following steps:

If not already running, start Apache and the WebLogic administration server.

Launch the administration console. Click Lock & Edit in the Change Center panel. Then select Environment > Servers from the Domain Structure panel.

Select one of your clustered managed servers:

Click the Configuration > Cluster tab:

Enter the following values:

Field	Value
Replication Group	dizzyRepGroup1
Preferred Secondary Group	dizzyRepGroup2

Click the Save button.

Repeat the previous steps to configure the same Replication Group and Preferred Secondary Group for the second managed server in the cluster.

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

Click Activate Changes in the Change Center panel. Start your clustered managed servers.

Back to Topic List

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.

Back to Topic List

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.

Back to Topic List

Initializing a Database to Support JDBC Replication

Perform the following steps:

Download the jdbc_replication_oracle.sql SQL script. If your database is not Oracle, obtain the necessary SQL from the WebLogic Server online documentation.

Use the utilities provided by your database to execute jdbc_replication_oracle.sql.

Use the utilities provided by your database to verify that it contains a new table named WL_SERVLET_SESSIONS.

Back to Topic List

Targeting a JDBC Data Source to a Cluster

Perform the following steps:

1.	Return to the administration console and click Lock & Edit in the Change Center panel. Then select Services > JDBC > Data Sources from the Domain Structure panel:
2.	Click the New button:
3.	Enter the value SessionDS for the fields Name and JNDI Name. Specify the type of your database and select an appropriate driver. Be sure to select a non-XA driver:
4.	Accept the default transaction settings and click Next.
5.	Enter the required properties to connect to your database, and click Next. Then click Finish.
6.	Select your new data source.
7.	Click the Targets tab:
8.	Target the data source to the entire cluster: Click Save.
9.	Click Activate Changes in the Change Center panel.

Back to Topic List

Configuring a Web Application for JDBC Replication

Perform the following steps:

1.	Once again, edit the shoppingcart/WEB-INF/weblogic.xml file.
2.	Change the <session-descriptor> element to support JDBC replication: <session-descriptor> <persistent-store-type>jdbc</persistent-store-type> <persistent-store-pool>SessionDS</persistent-store-pool> <persistent-store-table>WL_SERVLET_SESSIONS</persistent-store-table> </session-descriptor>
3.	Re-create shoppingcart.war by using any archive utility. Overwrite the existing file. For example: > cd shoppingcart > jar cf ../shoppingcart.war *
4.	Use the administration console to update (redeploy) shoppingcart.war to the cluster:

Back to Topic List

Testing JDBC Replication

Perform the following steps:

1.	Test the shopping cart application again. Add several items to your cart and view its contents.
2.	Use the utilities provided by your database to inspect the contents of the WL_SERVLET_SESSIONS table. A row should exist with a value of "shoppingcart.war" for the column named WL_CONTEXT_PATH.
3.	Kill the server currently hosting the user's session.
4.	Use the application to view your shopping cart again, and confirm that its contents are still the same.
5.	Check which server the user failed over to. Tip: Because JDBC replication is being used, the user can be redirected to any server in the cluster.

Back to Topic List

Summary

In this lesson, you learned how to:

	Configure replication groups for a cluster
	Update a Web application to use in-memory or JDBC replication
	Create the necessary database structures to support JDBC replication

Back to Topic List

Related Information

Back to Topic List