Deep dive into WebSphere eXtreme Scale HTTP session management, Part 1: Understanding HTTP session management and how it works in WebSphere eXtreme Scale

This series of articles will help you to understand what benefit the HTTP session management function in IBM® WebSphere® eXtreme Scale can bring to IBM WebSphere Application Server. It will also explain what the similarities, differences, and advantages are compared with other session management technology, and how to use WebSphere eXtreme Scale in a cloud environment with IBM Workload Deployer. Part 1 begins with a look at HTTP session management fundamentals. This content is part of the IBM WebSphere Developer Technical Journal.

Ying Liu (cdlliuy@cn.ibm.com), Advisory Software Engineer, IBM

Ying Liu has worked in IBM SWG WebSphere products for about 7 years. She has experience on a variety of WebSphere products. Recently, Ying and other colleagues in China have been working on integrated solution for WebSphere Application Server and WebSphere Application Server stack products, and plan to generate more technical output related to integration scenarios.



Xi Kun Sun (sunxikun@cn.ibm.com), Managing Consultant, IBM

Xi Kun works in the China software development lab, and always pays interest to emerging IT technology, industry solutions client experience, and business model incubation.



Jun Guo Ku (kujunguo@cn.ibm.com), Advisory Software Engineer, IBM

Ku Jun Guo is an advisory software engineer in the China development lab. He has been working on WebSphere foundation products for six years. His areas of expertise include WebSphere Application Server on z/OS, WebSphere eXtreme Scale, and web technologies. He now focuses on cloud computing and related development. He lives in Beijing with his family.



30 January 2013

Also available in Chinese

Introduction

With the ever increasing rate of mobile Internet usage, social media, and personalized and customized advertising methods, there are more and more diverse ways for visitors to access your website. They bring vitality to the enterprise, but they can also bring unprecedented traffic peak. The amplification of site traffic continues to challenge the workload of the original business systems behind the scenes, often causing a list of performance problems. In the traditional three-tier business architecture, back end systems (which can include databases and mainframe applications like CICS®) are the most likely to see performance bottlenecks, and to extend these systems can often be very expensive.

IBM WebSphere eXtreme Scale operates as an in-memory grid to cache the required data for elastic scalability. This aims to decrease repeated data access and shorten the application path distance to reduce the workload for the back end systems and improve the overall system performance.

WebSphere eXtreme Scale can dynamically process, partition, replicate, and manage application data and business logic across hundreds of servers. It provides transactional integrity and transparent fail-over to ensure high availability, high reliability, and consistent response times. WebSphere eXtreme Scale is an essential distributed caching platform for elastic scalability and the next-generation cloud environments. (See Getting Started with WebSphere eXtreme Scale, Part 1: Understanding WebSphere eXtreme Scale and how it works for more background.)

WebSphere eXtreme Scale can integrate with other IBM products to improve overall system performance. One of the simplest examples is to integrate WebSphere eXtreme Scale and WebSphere Application Server for caching HTTP sessions in order to enhance IBM WebSphere Portal and IBM WebSphere Commerce performance.

This series of articles introduces the HTTP session management function in WebSphere eXtreme Scale, including implementation, integration, configuration, configuration analysis, and similarities and differences compared with other session management technologies. The concept of HTTP session management for the caching and backing up WebSphere Application Server HTTP sessions, and how to extend it to implement WebSphere eXtreme Scale HTTP sessions in practice, is the jumping off point for this article.

HTTP session management fundamentals

HTTP is a stateless “connect-request-response-close” -based communication protocol. As the web has become more and more dynamic, it is often required to maintain the communication state between the client and server sides to pass the client request to the server, and then handle the returned response from the server. Session is used to give the client the appearance of a persistent connection with the server.

Session data is stored on the server side and identified by sessionID. When you use a browser to access a web application, the server will check whether the HTTP request from the client side contains the sessionID. If the server fails to find the sessionID, or the required session data with the sessionID, it will create a new sesionID and return it back to the client side. If the server can find the sessionID and the required data, it will operate on the session data according to the HTTP request.

In Figure 1, you can clearly see the changes between the two successive requests from the client side. When the user sent out the first Logon request, it did not contain any HTTP cookie data. WebSphere Application Server created a new session after it received the request, with a sessionID of 0001iizTEJCHe9NsYabKKB4OYfx:172c2qu1u. The subsequent HTTP request contains the newly created sessionID, which was used to connect the two individual HTTP requests. (See Resources for details.)

Figure 1. sessionID Changes between the two successive requests
Figure 1. sessionID Changes between the two successive requests

If you want to use the session mechanism when developing a servlet or JSP for a web application, you can use the getSession() method of HttpServletRequest to obtain an HttpSession instance. Two of the most common methods for HttpSession are setAttribute() and getAttribute(), which are used to set and retrieve the session’s attribute value. In addition, the invalidate() method can be used to claim the invalidated session instance and destroy its relevant session data. Example code for this is shown in Listing 1.

Listing 1. HttpSession example
protected void doPost2(HttpServletRequest request, HttpServletResponse response) 
throws ServletException, IOException {
  
  HttpSession session = null ;
  String action = request.getParameter("action") ; 
  	
  try {
  
  	session = request.getSession() ;
int MAX_KEYS = 100 ;
  
  	if(action.equals("logon")) {
  		for (int i = 0 ; i < MAX_KEYS ; i ++) {
  			session.setAttribute("key_" + i, value) ;
  		}
  	} 
  	
  	if(action.equals("list")) {
  		Enumeration keys = session.getAttributeNames() ;
  		for (int i = 0 ; i < MAX_KEYS ; i ++) {
  			String key = "key_" + i ;
  			Object value = session.getAttribute(key) ;
  			if (value == null) {	
  				System.out.println("[List] Failed to get attribute.");
  				continue ;
  			}
  		}
  	}
  	
  	if(action.equals("logout")) {
  		session.invalidate() ;
  	}
  	
  
  }catch(Exception ex) {
  	ex.printStackTrace() ;
  	
  }
}

Session management in WebSphere Application Server can be configured in the three tiers:

  • Web container tier
  • Application tier
  • Web module tier.

In WebSphere Application Server V8.5, you can directly change the setting in the server template for the dynamic cluster to quickly configure the HTTP session management for the web container tier and avoid redundant work of configuring each cluster member. Figure 2 shows the session management configuration panel in WebSphere Application Server at the dynamic cluster level.

Figure 2. Configuration Menu for WebSphere Application Server v8.5 HTTP session Management
Figure 2. Configuration Menu for WebSphere Application Server v8.5 HTTP session Management

When maintaining session data on the server side, you need to create an associated data structure in the server’s memory. For some systems that experience a huge volume of site traffic, session could take up a large percentage of the memory space. You therefore need to reasonably configure the maximum in-memory session count and session timeout according to your actual environment situation, circled in Figure 2.

Maximum in-memory session count specifies the maximum number of sessions to maintain in memory for each web module. When the session count reaches its maximum size, but all of the session data is not yet expired, the session management facility removes the least recently used session to make room for the new one, which could interrupt the browsing experience for some users. Without enabling any session replication or persistence mechanism, you could enable the Allow overflow option to enable additional sessions to be stored in secondary tables to avoid the session data from reaching the upper limit. However, too much session data could increase the burden of the JVM and affect the storage of other application data, as well as increase the cost of garbage collection (GC).

In addition, because of session affinity, requests from the same client must be routed to the same server. If all the session data is stored on a single server instance and the server goes down, all of the session data maintained in memory will be lost, and all further requests will be returned to their original state. For a majority of the websites, especially an e-commerce one, this could have a negative impact on the user experience.

Replication management

The session replication mechanism in WebSphere eXtreme Scale addresses the session number limit problem on the application server side by avoiding a single point of failure. It also helps to share session information across cluster members.

After integrating WebSphere Application Server and WebSphere eXtreme Scale and enabling the WebSphere eXtreme Scale HTTP session management function, the WebSphere eXtreme Scale HTTP session management module replaces the original HTTP session management module in WebSphere Application Server. WebSphere eXtreme Scale HTTP session management provides in-memory session management for WebSphere Application Server and also manages the session replication and storage between the two, as shown in Figure 3.

Figure 3. Implementing HTTP session management
Figure 3. Implementing HTTP session management

After HTTP session management is initiated, WebSphere eXtreme Scale replicates every new session created on WebSphere Application Server into the grid container, once for every predefined session replication interval. The WebSphere eXtreme Scale container is located on another server instance where all of the other cluster members can share and obtain the session data. Should an application server go down, the other application servers can still obtain the latest session data to implement HTTP session failover.

In the case where the WebSphere Application Server in-memory session count reaches its maximum size, WebSphere eXtreme Scale removes the least recently used session to make room for the new one – but it does not remove the session replica. Even if WebSphere Application Server is not able to find the actual data for that session, it still can retrieve the replica from WebSphere eXtreme Scale.

“Session replicas” in Figure 3 refers to WebSphere eXtreme Scale’s data backup mechanism. Data maintained in the grid container has at least one primary data set, plus a number of replicas. The number of replicas depends on your configuration. Replica data is the most important mechanism for ensuring high availability of the cache data and failover. In an HTTP session management scenario, you decide when you need a replica, how many replicas are necessary, and the replica pattern (synchronous or asynchronous).

When using WebSphere eXtreme Scale HTTP session management, the sessionID mentioned above will be rewritten, along with more label information about the WebSphere eXtreme Scale container (Figure 4).

Figure 4. Example of HTTP session ID identifier for using WebSphere eXtreme Scale
Figure 4. Example of HTTP session ID identifier for using WebSphere eXtreme Scale

Compared with the session data in Figure 1, you can see that IBMSessionHandle and IBMID are added into the HTTP session, which are used to identify the session data maintained in the grid container of WebSphere eXtreme Scale. With these additional fields, the system can locate the replica in the grid container even if it cannot find the associated JSESSIONID in the WebSphere Application Server server. This is how WebSphere eXtreme Scale can achieve HTTP session failover across different cells.


Configuring WebSphere eXtreme Scale HTTP session management

To enable WebSphere eXtreme Scale HTTP session management, you don’t need to change your application code, but you do need to add the relevant configuration files when you package your application. However, the latest versions of WebSphere eXtreme Scale, version 8.5 and later, truly achieves “plug and play,” meaning you can easily enable WebSphere eXtreme Scale HTTP session management without making any changes to the existing application (including the code and the configuration files).

1. Installing WebSphere eXtreme Scale

Figure 5 shows the WebSphere Application Server and WebSphere eXtreme Scale deployment architecture for our sample scenario. In the topology, a WebSphere Application Server cluster is created on the application server side. WebSphere eXtreme Scale is installed in another standalone server and communicates with WebSphere Application Server through the Internet. The yellow elements in the figure indicate that different machines should be installed with different WebSphere eXtreme Scale media. For example, WebSphere eXtreme Scale client should be installed on the WebSphere Application Server side, and WebSphere eXtreme Scale server should be installed on the WebSphere eXtreme Scale grid container side.

Figure 5. Sample topology
Figure 5. Sample topology

Both WebSphere Application Server V8.5 and WebSphere eXtreme Scale V8.5 (and later) are installed using IBM Installation Manager. A repository for the installation media needs to be assigned before installation.

  1. Install WebSphere Application Server V8.5 first, followed by WebSphere eXtreme Scale V8.5 client for WebSphere Application Server (Figure 6). When selecting the installation path for WebSphere eXtreme Scale client, you need to specify the existing WebSphere Application Server installation path, and then augment the WebSphere Application Server profile for WebSphere eXtreme Scale after it is installed (Figure 6).
    Figure 6. Select WebSphere eXtreme Scale client for WebSphere Application Server V8
    Figure 6. Select WebSphere eXtreme Scale client for WebSphere Application Server V8
  2. Install WebSphere eXtreme Scale standalone server for creating the WebSphere eXtreme Scale catalog server and container server (Figure 7).
    Figure 7. Select WebSphere eXtreme Scale stand-alone environment
    Figure 7. Select WebSphere eXtreme Scale stand-alone environment
  3. In addition to the usual GUI installation, WebSphere eXtreme Scale also supports silent installation. First, however, you need to record the Response File with Installation Manager so that the background installation executes properly. The command is:

    <IM_Installation_Path>/IBMIM -skipInstall -acceptLicense -record /tmp/wxs.xml

    This command is used to create the Response File wxs.xml, based on your installation options. It does not execute the actual installation process.

    If you choose silent installation to install WebSphere eXtreme Scale client for WebSphere Application Server, you will need to use the –skipInstall command first to install WebSphere Application Server, and then use the same directory to install WebSphere eXtreme Scale client. If you do not use the same directory, Installation Manager will not be able to detect the location of WebSphere Application Server with the –skipInstall pattern, as it does not permit you to choose the WebSphere eXtreme Scale client from WebSphere Application Server media.

2. Remote grid configuration file

After installing the WebSphere eXtreme Scale server, you need to configure the WebSphere eXtreme Scale map according to the HTTP session management requirements.

There are two configuration files in the WebSphere eXtreme Scale container:

  • ObjectGrid.xml is used to configure the structure of the session map (sample in Listing 2).
  • ObjectGridDeployment.xml is used to configure the deployment characteristics of the session map (sample in Listing 3).

You can find sample versions of these configuration files under the directory path: <WXS_Standalone_Installation_Path>ObjectGrid/sesssion/samples.

Listing 2. ObjectGrid.xml sample
<?xml version="1.0" encoding="UTF-8"?>
<objectGridConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://ibm.com/ws/objectgrid/config ../objectGrid.xsd"
	xmlns="http://ibm.com/ws/objectgrid/config">

<objectGrids>
	<objectGrid name="session" txTimeout="30">
	<bean id="ObjectGridEventListener" className=
"com.ibm.ws.xs.sessionmanager.SessionHandleManager"/>
      		<backingMap name="objectgridSessionMetadata" pluginCollectionRef=
"objectgridSessionMetadata" readOnly="false" lockStrategy="PESSIMISTIC" 
ttlEvictorType="LAST_ACCESS_TIME" timeToLive="3600" copyMode="COPY_TO_BYTES"/>
         	<backingMap name="objectgridSessionAttribute.*" template="true" 
readOnly="false" lockStrategy="PESSIMISTIC" ttlEvictorType="NONE" 
copyMode="COPY_TO_BYTES"/>
         	<backingMap name="objectgridSessionTTL.*" template="true" 
readOnly="false" lockStrategy="PESSIMISTIC" ttlEvictorType="LAST_ACCESS_TIME" 
timeToLive="3600" copyMode="COPY_TO_BYTES"/>
	</objectGrid>
</objectGrids>

<backingMapPluginCollections>
   <backingMapPluginCollection id="objectgridSessionMetadata">
       <bean id="MapEventListener" className=
"com.ibm.ws.xs.sessionmanager.MetadataMapListener"/>
    </backingMapPluginCollection>
</backingMapPluginCollections>
</objectGridConfig>
Listing 3. ObjectGridDeployment.xml sample
<?xml version="1.0" encoding="UTF-8"?>
<deploymentPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ibm.com/ws/objectgrid/deploymentPolicy 
../deploymentPolicy.xsd"
xmlns="http://ibm.com/ws/objectgrid/deploymentPolicy">

<objectgridDeployment objectgridName="session">
<mapSet name="sessionMapSet" numberOfPartitions="47" minSyncReplicas="0" 
maxSyncReplicas="0" maxAsyncReplicas="1" developmentMode="false" 
placementStrategy="FIXED_PARTITIONS">
           	 <map ref="objectgridSessionMetadata"/>
           	 <map ref="objectgridSessionAttribute.*"/>
           	 <map ref="objectgridSessionTTL.*"/>
	</mapSet>
    </objectgridDeployment>
</deploymentPolicy>

You can tune the parameters in ObjectGridDeployment.xml according to your business needs; for example, number of partitions, replica configuration, and so on. See the WebSphere eXtreme Scale Information Center for details about which parameters can be changed and which ones cannot.

For the purpose of the example presented here, all of the synchronous and asynchronous replicas are disabled, and the value of numberOfPartitions is set at 23. The other attribute values are the same as in the example file.

3. Enable WebSphere eXtreme Scale remote grid

In the topology shown in Figure 5, two servers (wasvm47 and wasvm48) are used to avoid a single point of failure for the WebSphere eXtreme Scale catalog server. The commands to enable the catalog servers cat 1 and cat2 are:

<WXS_Standalone_Installation_Path>/ObjectGrid/bin/startOgServer.sh cat1 -catalogServiceEndPoints cat1:wasvm47.cn.ibm.com:6601:6602,cat2:wasvm48.cn.ibm.com:6601:6602

<WXS_Standalone_Installation_Path>/ObjectGrid/bin/startOgServer.sh cat2 -catalogServiceEndPoints cat1:wasvm47.cn.ibm.com:6601:6602,cat2:wasvm48.cn.ibm.com:6601:6602

The commands to enable WebSphere eXtreme Scale containers con1 and con2 are:

<WXS_Standalone_Installation_Path>/ObjectGrid/bin/startOgServer.sh con1 -objectGridFile /opt/ISD/objectGrid.xml -deploymentPolicyFile /opt/ISD/objectGridDeployment.xml -catalogServiceEndPoints wasvm47.cn.ibm.com:2809,wasvm48.cn.ibm.com:2809 -jvmArgs -Xms256M -Xmx1G

<WXS_Standalone_Installation_Path>/ObjectGrid/bin/startOgServer.sh con2 -objectGridFile /opt/ISD/objectGrid.xml -deploymentPolicyFile /opt/ISD/objectGridDeployment.xml -catalogServiceEndPoints wasvm47.cn.ibm.com:2809,wasvm48.cn.ibm.com:2809 -jvmArgs -Xms256M -Xmx1G

In the above commands, 6601 and 6602 are the communication ports between the catalog servers, and 2809 is the communication port for the WebSphere eXtreme Scale container, WebSphere eXtreme Scale client side, and catalog server.

4. Configure catalog server in WebSphere eXtreme Scale client side

According to the topology in Figure 5 and the installation instructions above, you need to install WebSphere eXtreme Scale client side into the WebSphere Application Server. Once complete, you can access the WebSphere Application Server administrative console and see the label for WebSphere eXtreme Scale, as shown in Figure 8.

Figure 8. WebSphere Application Server admin console after Installing WebSphere eXtreme Scale client
Figure 8. WebSphere Application Server admin console after Installing WebSphere eXtreme Scale client

In the WebSphere Application Server admin console, you can configure the catalog domain for WebSphere eXtreme Scale client, so that the WebSphere eXtreme Scale client can communicate with the catalog server. In the admin console, navigate to System Administration > WebSphere eXtreme Scale > Catalog Service Domains. Select the option to create a new domain. Enter the hostname and listerner port of the catalog server, as shown in Figure 9.

Figure 9. Configure catalog service domain
Figure 9. Configure catalog service domain

5. Enable WebSphere eXtreme Scale HTTP session management

To configure an HTTP session, navigate to your server definition. (You can create a new server or edit and use an existing one of this purpose.) After installing WebSphere eXtreme Scale client, access the admin console and navigate to Servers > Clusters > Dynamic clusters > <Dynamic Cluster Name> > Server Template > Session Management. A new option for eXtreme Scale session management settings is displayed (Figure 10).

Select Enable Session Management and Remote eXtreme Scale Data Grid. Name the Catalog service Domain and Grid Name according to the predefined WebSphere eXtreme Scale grid architecture (Figure 10).

Figure 10. Configure WebSphere eXtreme Scale HTTP session management
Figure 10. Configure WebSphere eXtreme Scale HTTP session management

Here are a few tips to consider when using WebSphere eXtreme Scale HTTP session management:

  • Be sure to select Allow overflow in the General Properties page (Figure 11). When the maximum in-memory session count reaches 1000, WebSphere eXtreme Scale will create the 1001th session object, replicate it to the WebSphere eXtreme Scale grid, and then remove the least recently used session to meet the maximum in-memory count. If overflow is not enabled, WebSphere eXtreme Scale will simply remove the “inactive” session and then create a new session. The latter scenario can introduce quite a bit of latency when traffic volume is high and have a negative impact on overall performance.
    Figure 11. Select Allow overflow
    Figure 11. Select Allow overflow
  • Be sure the other session replication and persistent mechanisms are disabled, which means the None option should be checked in the Distributed Environment Setting menu. Although WebSphere eXtreme Scale HTTP session management can detect the other session replication and persistence configuration, it cannot disable them. When more than one session replication and persistence mechanisms are enabled, it will bring extra I/O cost and affect system performance.
Figure 12. Disable other session replication and persistent mechanism
Figure 12. Disable other session replication and persistent mechanism

6. Configure WebSphere eXtreme Scale HTTP session management

This section describes optional steps for WebSphere eXtreme Scale HTTP session management configuration. You can use the default settings provided by WebSphere eXtreme Scale as is, or you can refer here to apply additional customization.

The configuration file name for WebSphere eXtreme Scale HTTP session management is splicer.properties. After enabling WebSphere eXtreme Scale HTTP session management, the WebSphere eXtreme Scale client will automatically create the associated splicer.properties file. The specific location will differ according to the session management configuration level.

As mentioned in the earlier, you can define session management for a dynamic cluster. From the admin console, navigate to Servers > Clusters > Dynamic clusters > <Dynamic Cluster Name> > Server Template >> Administration > Custom properties. The value of attribute com.ibm.websphere.xs.sessionFilterProps contains the location of the splicer.properties file (Figure 13).

Figure 13. Location of Splicer.properties file
Figure 13. Location of Splicer.properties file

If WebSphere eXtreme Scale HTTP session management is disabled, the splicer.properties file will be removed automatically. The attribute com.ibm.websphere.xs.sessionFilterProps will only be created when you enable WebSphere eXtreme Scale HTTP session management. Once you disable it, this attribute will be removed as well. If you manually create the attribute, WebSphere eXtreme Scale HTTP session management will be automatically enabled, remove the attribute, then be disabled automatically.

Listing 4 shows the default configuration attributes in the Splicer.properties file.

Listing 4. Example of Splicer.properties File
# Generated by writeSplicerFile() at Fri Aug 17 04:13:31 EDT 2012
useURLEncoding=false
useCookies=true
objectGridType=REMOTE
reuseSessionId=true
webSphereCatalogDomain=mycatdomain
objectGridName=session
replicationInterval=10
sessionTableSize=1000
fragmentedSession=true
sessionManagementType=XSRemoteSessionManagement

This file contains three types of parameters:

  • Type 1

    Basic information for WebSphere eXtreme Scale grid, which includes objectGridType, objectGridName, webSphereCatalogDomain, and sessionManagementType. These four parameters are set when you enable WebSphere eXtreme Scale HTTP session management through the admin console. Do not edit these parameters manually.

  • Type 2

    Parameters for session processing mode, including:

    • useURLEncoding: When you need to use URL rewriting to track session information, you can set the value of this parameter to true. In the Splicer.properties file, the value of useURLEncoding should be consistent with the relevant parameters of the web container after enabling WebSphere eXtreme Scale HTTP session management. After you enable WebSphere eXtreme Scale HTTP session management, if you change the Enable URL Rewriting option in the admin console page, you should disable and re-enable WebSphere eXtreme Scale HTTP session management in order to refresh the Splicer.properties file.
    • useCookies: The default is true. Session information is stored in a cookie.
    • reuseSessionId: The default is true. When session failure recovery occurs, it still uses the previous sessionID.
  • Type 3

    Parameters for WebSphere eXtreme Scale HTTP session management performance, including:

    • replicationInterval: The default is 10, which means for every 10 seconds, WebSphere eXtreme Scale replicates the in-memory session objects in WebSphere Application Server to the WebSphere eXtreme Scale grid. This is an asynchronous replication mode. If WebSphere Application Server goes down during the replication interval, the session objects during these 10 seconds will get lost (at most). You can tune the replicationInterval parameter according to the importance of your application session data. When the value of replicationInterval is set to 0, WebSphere eXtreme Scale will perform synchronous replication. On the other hand, this will bring a performance cost for the system. (A subsequent article will compare the performance of synchronous and asynchronous replication.)
    • sessionTableSize: When the value of objectGridType is Remote, WebSphere eXtreme Scale uses sessionTableSize parameter to control the number of the in-memory session object on the WebSphere Application Server server side, the default value for sessionTableSize is 1000. Meanwhile, the original Maximum in-memory session count in the Admin console will be invalidated. To avoid confusion, set the value of sessionTableSize larger than the one of Maximum in-memory session count. Although WebSphere eXtreme Scale can provide more memory space for storing session objects, it is still better to set a relatively large value of sessionTableSize, because frequently replicating data from WebSphere eXtreme Scale grid to WebSphere Application Server will consume more compute capacity and affect overall performance.
    • fragmentedSession: This parameter is used to set the mode to store session data. The default is true, which means WebSphere eXtreme Scale stores each attribute separately. When using session.getAttribute() method, you can only get the relevant attribute value. If you set fragmentedSession to false, WebSphere eXtreme Scale stores session data as a whole entry. And you will get the entire session data by using the session.getAttribute() method. In Listing 1, every session object contains 100 attributes, so it is better to set fragmentedSession to be true in order to get better performance.

7. Verify WebSphere eXtreme Scale HTTP session management has been enabled

Method 1: Verify the sessionID value received from the browser. After enabling a WebSphere eXtreme Scale HTTP session, the sessionID should looks like the example in Figure 4.

Method 2: Check the WebSphere eXtreme Scale grid content to verify session object has been stored. In Listing 1, Logon will set the value of the 100 attributes for the newly created session, therefore, there are also 100 session attributes stored in the WebSphere eXtreme Scale grid.

You can run the command below to show the WebSphere eXtreme Scale grid content; the result is shown in Listing 5.

<WXS_Standalone_Installation_Path>/ObjectGrid/bin/xscmd.sh -c showMapSizes -cep wasvm47.cn.ibm.com:2809,wasvm48.cn.ibm.com:2809

Listing 5. showMapSizes running result
Starting at: 2012-08-16 22:08:24.177

CWXSI0068I: Executing command: showMapSizes

*** Displaying results for session data grid and sessionMapSet map set.

*** Listing maps for con1 ***
Map Name                          Partition Map Entries Used Bytes Shard Type Container
--------                          --------- ----------- ---------- ---------- ---------
objectgridSessionAttributeEvicted 11        0           0          Primary    con1_C-0
objectgridSessionAttributeEvicted 12        0           0          Primary    con1_C-0
objectgridSessionAttributeEvicted 13        0           0          Primary    con1_C-0
objectgridSessionAttributeEvicted 14        0           0          Primary    con1_C-0
objectgridSessionAttributeEvicted 15        0           0          Primary    con1_C-0
objectgridSessionAttributeEvicted 16        0           0          Primary    con1_C-0
objectgridSessionAttributeEvicted 17        0           0          Primary    con1_C-0
objectgridSessionAttributeEvicted 18        0           0          Primary    con1_C-0
objectgridSessionAttributeEvicted 19        0           0          Primary    con1_C-0
objectgridSessionAttributeEvicted 20        0           0          Primary    con1_C-0
objectgridSessionAttributeEvicted 21        0           0          Primary    con1_C-0
objectgridSessionAttributeEvicted 22        0           0          Primary    con1_C-0
objectgridSessionMetadata         11        0           0          Primary    con1_C-0
objectgridSessionMetadata         12        0           0          Primary    con1_C-0
objectgridSessionMetadata         13        0           0          Primary    con1_C-0
objectgridSessionMetadata         14        0           0          Primary    con1_C-0
objectgridSessionMetadata         15        0           0          Primary    con1_C-0
objectgridSessionMetadata         16        0           0          Primary    con1_C-0
objectgridSessionMetadata         17        0           0          Primary    con1_C-0
objectgridSessionMetadata         18        0           0          Primary    con1_C-0
objectgridSessionMetadata         19        0           0          Primary    con1_C-0
objectgridSessionMetadata         20        0           0          Primary    con1_C-0
objectgridSessionMetadata         21        0           0          Primary    con1_C-0
objectgridSessionMetadata         22        0           0          Primary    con1_C-0
Server total: 0 (0 B)

*** Listing maps for con2 ***
Map Name                          Partition Map Entries Used Bytes Shard Type Container
--------                          --------- ----------- ---------- ---------- ---------
objectgridSessionAttribute        0         100         30 KB      Primary    con2_C-0
objectgridSessionAttributeEvicted 0         0           0          Primary    con2_C-0
objectgridSessionAttributeEvicted 1         0           0          Primary    con2_C-0
objectgridSessionAttributeEvicted 2         0           0          Primary    con2_C-0
objectgridSessionAttributeEvicted 3         0           0          Primary    con2_C-0
objectgridSessionAttributeEvicted 4         0           0          Primary    con2_C-0
objectgridSessionAttributeEvicted 5         0           0          Primary    con2_C-0
objectgridSessionAttributeEvicted 6         0           0          Primary    con2_C-0
objectgridSessionAttributeEvicted 7         0           0          Primary    con2_C-0
objectgridSessionAttributeEvicted 8         0           0          Primary    con2_C-0
objectgridSessionAttributeEvicted 9         0           0          Primary    con2_C-0
objectgridSessionAttributeEvicted 10        0           0          Primary    con2_C-0
objectgridSessionMetadata         0         1           1 KB       Primary    con2_C-0
objectgridSessionMetadata         1         0           0          Primary    con2_C-0
objectgridSessionMetadata         2         0           0          Primary    con2_C-0
objectgridSessionMetadata         3         0           0          Primary    con2_C-0
objectgridSessionMetadata         4         0           0          Primary    con2_C-0
objectgridSessionMetadata         5         0           0          Primary    con2_C-0
objectgridSessionMetadata         6         0           0          Primary    con2_C-0
objectgridSessionMetadata         7         0           0          Primary    con2_C-0
objectgridSessionMetadata         8         0           0          Primary    con2_C-0
objectgridSessionMetadata         9         0           0          Primary    con2_C-0
objectgridSessionMetadata         10        0           0          Primary    con2_C-0
Server total: 101 (31 KB)

Total catalog service domain count: 101 (31 KB)
(The used bytes statistics are accurate only when you are using simple objects or the 
COPY_TO_BYTES copy mode.)

CWXSI0040I: The showMapSizes command completed successfully.

Ending at: 2012-08-16 22:08:26.145

In Listing 5, it is clear that there are 100 session attributes separately stored in map objectgridSessionAttribute. The metadata value of the current session object is stored in map objectgridSessionMetadata. The 31 KB data written to WebSphere eXtreme Scale grid shows that WebSphere eXtreme Scale HTTP session management has been enabled successfully.


Conclusion

Part 1 of this series of articles introduced the basic concept of HTTP session management, and described how to configurate WebSphere eXtreme Scale HTTP session management. Subsequent articles will continue to analyze WebSphere eXtreme Scale HTTP session management, traditional database persistence and memory–to-memory replication, and how to use WebSphere eXtreme Scale in an IBM Workload Deployer cloud platform.

Resources

Learn

Get products and technologies

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=856658
ArticleTitle=Deep dive into WebSphere eXtreme Scale HTTP session management, Part 1: Understanding HTTP session management and how it works in WebSphere eXtreme Scale
publish-date=01302013