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.
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.
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 oppositeReplication 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.
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.
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.
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.
Bookmark
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.)
