How to inspect the values stored in the Portlet Session

In the How to check what objects are stored in HttpSesession entry i mentioned about how to use the com.ibm.ws.webcontainer.httpsession.SessionInspectServlet servlet for inspecting content of a servlet.

The PortletSession object is based on HttpSession, with difference that when you store attribute in the PortletSession in PORTLET_SCOPE , the portal server will name space that attribute and store it in the HttpSession, You can also set an attribute in the PortletSession using APPLICATION_SCOPE it will be stored in the HttpSession without any name spacing.

The side effect of this layering is we can use the same SessionInspectionServlet for inspecting content of a PortletSession.

If you want to use SessionInspectionServlet then you need to make sure that value of enable-serving-servlets-by-class-name is set to true in your ibm-web-ext.xmi file. By default when you create a portlet this value is set to true(You might to add a step to set enable-serving-servlets-by-class-name to false in your security hardening procedure). You can check this value by going to WebSphere\wp_profile\installedApps\\.ear\Contact.war\WEB-INF\ibm-web-ext.xmi for portlet that is installed on your portal, for the portlets that your running through the RAD just check that value in portlet application inside your workspace.

Once you ensure that enable-serving-servlets-by-class-name is set to true the next step would be to figure out the context path of your portlet .war file. You can do this by looking at ibm-web-ext.xmi file of the portlet that you deploy through RAD

<?xml version="1.0" encoding="UTF-8"?>
<web-ext
 xmlns="http://websphere.ibm.com/xml/ns/javaee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee
 http://websphere.ibm.com/xml/ns/javaee/ibm-web-ext_1_0.xsd"
 version="1.0">

 <reload-interval value="3"/>
 <context-root uri=".ActionScopeRequestAttribute" />
 <enable-directory-browsing value="true"/>
 <enable-file-serving value="true"/>
 <enable-reloading value="true"/>
 <enable-serving-servlets-by-class-name value="true" />

</web-ext>

Value of uri attribute in context-root element defines the context-root of your web application.

If your portlet is installed using Portal admin console then you will have to look inside the application.xml in the WebSphere\wp_profile\installedApps\\.ear\META-INF folder

<?xml version="1.0" encoding="UTF-8"?><application id="Application_ID" version="5" 
xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
 http://java.sun.com/xml/ns/javaee/application_5.xsd">
    <display-name>Contact_war</display-name>
    <module>
        <web>
            <web-uri>Contact.war</web-uri>
            <context-root>/wps/PA_Contact</context-root> 
        </web>
    </module>
</application>

The value of context-root is used for defining the context-root of your portlet. Once you know the context-root go to http://localhost:10039/context-root/servlet/com.ibm.ws.webcontainer.httpsession.SessionInspectServlet URL for inspecting value of the servlet.

In order to test this feature i did create a portlet that sets one session attribute in PORTLET_SCOPE and other session attribute in APPLICATION_SCOPE, i did hit the portlet so that the values get set in PorteltSession, this is how my code looks like

request.getPortletSession().setAttribute("applicationScopeAttribute", 
"testValue",PortletSession.APPLICATION_SCOPE);
request.getPortletSession().setAttribute("portletScopeAttribute", 
"testValue",PortletSession.PORTLET_SCOPE);

Now in the same browser i did open another tab and when i did hit the SessionInspection servlet this is what i see



As you can see the attribute stored in APPLICATION_SCOPE gets stored as it is. But for the attribute that is stored in PORTLET_SCOPE the portal server will add javax.portlet.p.<portletwindowid>? prefix

How to check what objects are stored in HttpSesession

You might want to check what objects are stored in HttpSession because either your application is throwing java.io.NotSerializableException or during performance testing you want to check size of the objects stored in session.

The WebSphere Application Server ships a com.ibm.ws.webcontainer.httpsession.SessionInspectServlet servlet that can be used to find out what is content of the session as well as size of the objects stored in session. The SessionInspectionServlet is part of AppServer/plugins/com.ibm.ws.webcontainer.jar, which is already on your web applications class path. So in order to use the SessionInspectionServlet, you will have two choices

1. Define the SessionInspectionServlet in your web.xml and map it to a URI


2. Enable Serving servlets by class name, you can set this value in the ibm-web-ext.xml
   
   
   

   
   <?xml version="1.0" encoding="UTF-8"?>
   <web-ext
    xmlns="http://websphere.ibm.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee 
    http://websphere.ibm.com/xml/ns/javaee/ibm-web-ext_1_0.xsd"
    version="1.0">
   
    <reload-interval value="3"/>
    <enable-directory-browsing value="true"/>
    <enable-file-serving value="true"/>
    <enable-reloading value="true"/>
   
    <enable-serving-servlets-by-class-name value="true" />
   
   </web-ext>
   

   
   

After making this change restart your web application and then access your web application so that the attributes/ objects are added into HttpSession, once that part is done you can access the SessionInspectionServlet and it will show you output like this




In my case i did create a simple SessionInspectionServletDemo servlet like this

package com.webspherenotes.session;

import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;

/**
 * Servlet implementation class SessionInspectionServletDemo
 */
public class SessionInspectionServletDemo extends HttpServlet {
 private static final long serialVersionUID = 1L;
 
 protected void doGet(HttpServletRequest request, HttpServletResponse response) 
 throws ServletException, IOException {
  response.setContentType("text/html");
  response.getWriter().println("Inside SessionInspectionServletDemo");
  HttpSession session = request.getSession();
  session.setAttribute("testName", "testValue");
  Contact c = new Contact();
  session.setAttribute("contact", c);
  
 }
}

Inside the doGet() method i a am adding a testName attribute with String value and a contact attribute with object of non Serializable Contact object as value.

I made changes in the Contact object to implement java.io.Serializable interface and now i can see that the SessionInspectionServlet servlet does not list it under the Non-Seiralizable object and it also shows the size of the session

Effect on JSESSIONID in case of Server failure

Server clusters provide a solution for failure of an application server. Sessions created by cluster members in the server cluster share a common persistent session store. Therefore, any cluster member in the server cluster has the ability to see any user’s session saved to persistent storage. If one of the cluster members fail, the user can continue to use session information from another cluster member in the server cluster. This is known as failover. Failover works regardless of whether the nodes reside on the same machine or several machines.

After a failure, WebSphere redirects the user to another cluster member, and the user’s session affinity switches to this replacement cluster member. After the initial read from the persistent store, the replacement cluster member places the user’s session object in the in-memory cache, assuming the cache has space available for additional entries.

The Web server plug-in maintains the cluster member list in order and picks the cluster member next in its list to avoid the breaking of session affinity. From then on, requests for that session go to the selected cluster member. The requests for the session go back to the failed cluster member when the failed cluster member restarts.

I tried this with my SessionAffinity.war, after establishing session with Server 2 i stopped that server and then i tried sending request to web server. The JSESSIONID was changed after 1 request and now the clone Id part was pointing to server 4

How to find out the WAS server handling request from JSESSIONID

Debugging problems in distributed environment is little more difficult then debugging problems in the Standalone environment, because how do you find out the server that is handling the request. The JSESSIONID cookie value contains the identifier of the server that is handling the request, take a look at Session Affinity for more details.

I wanted to try this so i created a simple SessionAffinityServlet like this

public class SessionAffinityServlet extends HttpServlet {
 private static final long serialVersionUID = 1L;
 protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
  response.setContentType("text/html");
  System.out.println("Inside SessionAffinity.doGet()");
  HttpSession httpSession = request.getSession();
  response.getWriter().println("Session Name " + ServerName.getFullName() +"
");
  response.getWriter().println("Session Id " + httpSession.getId() +"
");
  Cookie[] cookies = request.getCookies();
  for( int i = 0 ; i < cookies.length ;i++){
   response.getWriter().println(cookies[i].getName() + " " + cookies[i].getValue() +"
");
  }

 }
}

As you can see only thing that i am doing in the doGet() method is reading the value of all the cookies and writing them to output. I am also writing out name of the server handling the request in the output.

I deployed this code to server and when i tried hitting the server and i see values like this.




Now if i take the value of JSESSIONID the last part of the value is 14dtuu8g3. Now take this value and open the plugin-cfg.xml for web server plugin and search this value in it. You will find a Server element with value of CloneID matching the value from JSESSIONID that is the server dmgrNode01_server2 , handling the user request

<ServerCluster CloneSeparatorChange="false" GetDWLMTable="false" IgnoreAffinityRequests="true" LoadBalance="Round Robin" Name="cluster1" PostBufferSize="64" PostSizeLimit="-1" RemoveSpecialHeaders="true" RetryInterval="60">
<Server CloneID="14dtuu8g3" ConnectTimeout="0" ExtendedHandshake="false" LoadBalanceWeight="2" MaxConnections="-1" Name="dmgrNode01_server2" ServerIOTimeout="0" WaitForContinue="false">
<Transport Hostname="dmgr.webspherenotes.com" Port="9081" Protocol="http"/>
<Transport Hostname="dmgr.webspherenotes.com" Port="9444" Protocol="https">
<Property Name="keyring" Value="C:\Cert\HTTPServer\Plugins/config/webserver1/plugin-key.kdb"/>
<Property Name="stashfile" Value="C:\Cert\HTTPServer\Plugins/config/webserver1/plugin-key.sth"/>
</Transport>
</Server>
<Server CloneID="14dtuueci" ConnectTimeout="0" ExtendedHandshake="false" LoadBalanceWeight="2" MaxConnections="-1" Name="dmgrNode01_server4" ServerIOTimeout="0" WaitForContinue="false">
<Transport Hostname="dmgr.webspherenotes.com" Port="9082" Protocol="http"/>
<Transport Hostname="dmgr.webspherenotes.com" Port="9445" Protocol="https">
<Property Name="keyring" Value="C:\Cert\HTTPServer\Plugins/config/webserver1/plugin-key.kdb"/>
<Property Name="stashfile" Value="C:\Cert\HTTPServer\Plugins/config/webserver1/plugin-key.sth"/>
</Transport>
</Server>
<PrimaryServers>
<Server Name="dmgrNode01_server2"/>
<Server Name="dmgrNode01_server4"/>
</PrimaryServers>
</ServerCluster>


As you can see the plugin-cfg.xml has a ServerCluster element that has two Server child elements, that means the cluster has two servers and plugin will forward request to either of them

You can download the sample code from here

Distributed Session with database persistence

You can configure WAS so that the session information is stored in the database, so that if the server which was handling user request and where HttpSession was created fails and the request gets routed to other server, that server should be able to receive session information from DB.

You can follow these steps to configure DB based session persistence

• First create a JDBC data source with all rights. The reason being when you do that WAS will create the tables necessary to store session information in the target database. In my local environment i did create jdbc/sessionDB datasource pointing to my local Apache Derby server


• Then go to Application Servers > server_name > Session Management > Distributed environment setttings page and select database for storing distributed sessions
  
  


• Click on the Database link to configure the database connection
  
  


• Restart the cluster for new changes to take effect


• Use the Distributed Session Sample application to test the distributed session

First i tried using the single row option for storing my session information and this is what the JSESSIONID looked like JSESSIONID=0002ohdZQLH8oQu3Zvogc6c8a-y:14dtuu8g3:14dtuueci. I also tried looking at what data is getting stored in the db and it looked like the session data is getting stored in SESSIONS table



If you take a close look you will notice that one record is inserted in db with value of ID and PROPID column equal to part of the JSESSIONID cookie

Distributed Session Sample

I wanted to see how the distributed Session works so i created this DistributeSessionSample.war file. This Web Application has a simple DistributedSessionSample servlet like this

public class DistributeSessionSample extends HttpServlet {
 private static final long serialVersionUID = 1L;

 protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
  System.out.println("Entering DistributeSessionSample.doGet()");
  HttpSession httpSession = request.getSession();
  System.out.println("HttpSession Object " + httpSession);
  String serverName = (String)httpSession.getAttribute("serverName");
  System.out.println("Server Name " + serverName);
  if(serverName == null){
   System.out.println("Server Name is empty. Adding data to HttpSession");
   serverName = ServerName.getDisplayName() + new Date();
   httpSession.setAttribute("serverName", serverName);
  }
  response.setContentType("text/html");
  response.getWriter().println("Server Name from Http Session " + serverName +"
 ");
  response.getWriter().println("Server Display Name " + ServerName.getDisplayName() +"
 ");
  response.getWriter().println("Server Full Name " + ServerName.getFullName() +"
 ");
  response.getWriter().println("Server Id " + ServerName.getServerId() +"
 ");
  System.out.println("Exiting DistributeSessionSample.doGet()");
 }

}

In this servlet first i retrieve object of HttpSession from the current request. Then i check if it has serverName, if yes then retrieve its value and print it in output if not read name of the server that is handling current request and put it in session.

On my local machine i do have a cluster that has 2 servers, i deployed this application on my cluster and then i tried hitting the DistributedSessionSample from first server directly and i got this response.




Then i changed URL so that the request goes to Server 2 and while sending request to Server 2 it will send the JSESSIONID cookie based on that cookie server2 should be able to retrieve session object and retrieve the name of the server stored in the HttpSession. This is the output that i get on second server

To configure memory-to-memory replication for session manager

You can configure distributed session to use memory-to-memory to replication. Once you configure that whenever WAS creates a HTTPSesion it replicates the session data to other application server in the cluster and if for some reason the server where you created session gets down you can access the data from other session.

If you used created a replication domain while creating cluster every thing that is needed for memory-to-memory replication for HTTPSession is already configured and you dont have to make any changes.

But if you did not do that at the time of cluster creation then you will have to follow these steps

1. Create a Replication domain using WAS Admin Console, like this
   
   


2. Follow these steps for each application server in your cluster, In the WAS Admin Console, go to Servers > Application servers > server_name > Container Settings > Web Container Settings > Session management
   
   
   Click Memory to Memory replication radio box and click on the link
   


3. On the next screen Replication domain and the Replication mode as both client and server like this
   
   

Now your cluster is configured to use Memory to Memory replication for session distribution

Persistence session management

By default, WebSphere places session objects in memory. However, the administrator has the option of enabling persistent session management, which instructs WebSphere to place session objects in a persistent store. There are two ways to configure session persistence in WebSphere Application Server V6

• Database persistence


• Memory-to-memory session state replication using the data replication
  service available in distributed server environments

Fail Over

Server clusters provide a solution for failure of an application server. Sessions created by cluster members in the server cluster share a common persistent session store. Therefore, any cluster member in the server cluster has the ability to see any user’s session saved to persistent storage. If one of the cluster members fail, the user can continue to use session information from another cluster member in the server cluster. This is known as failover. Failover works regardless of whether the nodes reside on the same machine or several machines

After a failure, WebSphere redirects the user to another cluster member, and the user’s session affinity switches to this replacement cluster member. After the initial read from the persistent store, the replacement cluster member places the user’s session object in the in-memory cache, assuming the cache has space available for additional entries.

The Web server plug-in maintains the cluster member list in order and picks the cluster member next in its list to avoid the breaking of session affinity. From then on, requests for that session go to the selected cluster member. The requests for the session go back to the failed cluster member when the failed cluster member restarts.

Session Affinity

The Servlet Specification 2.4 requires that HTTP session be

Accessible only to the web application that created the session. The Session ID but not the session data, can be shared across Web Applications.

Handled by a single JVM for that application at any one time.

In a clustered environment, any HTTP requests associated with an HTTP session must be routed to the same Web application in the same JVM. This ensures that all of the HTTP requests are processed with a consistent view of the user’s HTTP session. The exception to this rule is when the cluster member fails or has to be shut down.

WebSphere is able to assure that session affinity is maintained in the following way: Each server ID is appended to the session ID. When an HTTP session is created, its ID is passed back to the browser as part of a cookie or URL encoding. When the browser makes further requests, the cookie or URL encoding will be sent back to the Web server. The Web server plug-in examines the HTTP session ID in the cookie or URL encoding, extracts the unique ID of the cluster member handling the session, and forwards the request.


The JSESSIONID cookie can be divided into four parts: cache ID, session ID, separator, clone ID, and partition ID (new in V6). JSESSION ID will include a partition ID instead of a clone ID when memory-to-memory replication in peer-to-peer mode is selected. Typically, the partition ID is a long numeric number.

For example the JSESSIONID cookie value of 0000HHAnbYWnNxGD-iVupvcArfr:14dtuueci is made up of these four parts

• Cache ID 0000


• Session ID: HHAnbYWnNxGD-iVupvcArfr


• separator :


• Clone ID: 14dtuueci

URL Rewriting for session tracking

URL rewriting works by storing the session identifier in the page returned to the user. WebSphere encodes the session identifier as a parameter on URLs that have been encoded programmatically by the Web application developer. This is an example of a Web page link with URL encoding:


<a href="/store/catalog;$jsessionid=DA32242SSGE2">


When the user clicks this link to move to the /store/catalog page, the session
identifier passes into the request as a parameter.

URL rewriting requires explicit action by the Web application developer. If the servlet returns HTML directly to the requester, without using a JavaServer Page, the servlet calls the API

out.println("<a href=\");
out.println(response.encodeURL ("/store/catalog"));
out.println("\>catalog</a>");

The fact that the servlet or JSP developer has to write extra code is a major drawback over the other available session tracking mechanisms. URL rewriting limits the flow of site pages exclusively to dynamically generated pages, such as pages generated by servlets or JSPs. WebSphere inserts the session ID into dynamic pages, but cannot insert the user’s session ID into static pages, .htm, or .html.
Therefore, after the application creates the user’s session data, the user must visit dynamically generated pages exclusively until they finish with the portion of the site requiring sessions. URL rewriting forces the site designer to plan the user’s flow in the site to avoid losing their session ID.

Setting permenanet cookies using WebSphere Application Server

By default the value of Cookie Maximum age is set to Current browser session, so what that means is that the HttpSession is maintained in the browsers memory and stays there till the users browser is open. And when user browser is closed the HTTPSession information is lost, so if user browser is closed or crashed for some reason, if he opens a new browser his HTTP Session information will be lost and user will have to login again.

You might have a business requirement, where you might want to maintain users session across multiple browser session. Ex. you might want to remember user for next 10 days. In that case you can Check the Set Maximum age radio button and set maximum age to say 864000 seconds.


After you made that change when user logs in you can generate his HTTPSession object and when the JSESSIONID cookie is sent it will look like this. Did you see the Expiration time is set to after 10 days.


Now close your browser and restart new instance, if you go to show cookies you will notice that the JSESSIONID generated for user is still there. Now if user makes any request to localhost before the cookie is expired then browser will include this cookie in the request and on the server side you can use the JSESSIONID to identify the user and let him resume his work

Configuring Cookie based session tracking

If you decide to use Cookies for session tracking then you can configure that behavior by clicking on Enable cookies hot link, you will get a screen like this

1. Cookie Name: As per Servlet specification 2.4 the cookie name should be JSESSIONID. But you can change the cookie name



2. Restrict cookies to HTTP Session: Enabling this feature restricts the exchange of cookies only to HTTPS sessions.



3. Cookie maximum age: The amount of time that the cookie will live in the client browser. There are two choices:
   
   
   
   • Expire at the end of the current browser session
   
   
   • Expire at a configurable maximum age
   
   If you choose the maximum age option, specify the age in seconds.
   
   
   

In addition to that there are two more properties that you can configure Cookie Domain and Cookie Path, Before we talk about that we will have to cover how the cookies work, When user makes a request to the server for the first time, server will generate a HTTP Session and return that cookie to the browser. After that whenever browser is making request to server it includes that cookie in header so that server can find out the user based on that cookie. The way cookies work in browsers is that you can limit the requests to which browser will forward the cookie Ex. lets say your environment you have public.webspherenotes.com and private.webspherenotes.com, and you configured your cookie domain to private.webspherenotes.com. Now if you go to webspherenotes.com server will generate cookie and send it to browser. Now if your browser is sending next request to webspherenotes.com it will check the domain of request if it is public.webspherenotes.com it wont include the cookie and that way server wont have any way of knowing that this request is coming from user1.

Same thing applies to cookie path, you can configure the path to say to say dynamic so that browser will include cookie when making request to www.webspherenotes.com/dynamic but not when you make request to www.webspherenotes.com/images or www.webspherenotes.com/js

Cookie for session tracking

Cookies is the most commonly used method for tracking user session. The way it works is WebSphere Application server's session support generates a unique session ID for each user, and returns this ID to the users browser with cookie. There after whenver browser is making requests browser would send that cookie in header to the server and whenver server is generating response it will send that cookie information in header to the browser. By default websphere uses temporary cookies i.e. cookie which is not written to users machine to store session information, the cookie gets destroyed if the browser is closed. The cookie holds session identifier but the actual session information is stored on the server. The default name of the session management cookie is JSESSIONID

Main disadvantage with cookies is taht some users, either by choice or mandage, disable them from within their browsers.

SSL ID Session Tracking

SSL Tracking is supported only for the IBM HTTP Server and SUN one Web Server.

When SSL ID tracking is enabled for requests over SSL, SSL session information is used to track the HTTP session ID. Since the SSL session ID is negoitated between the HTTP server and browser, it cannot survive the HTTP Server crash However, the failure of an application server does not affect the SSL session ID and if the distributed session is not enabled the session itself is lost.The lifetime of an SSL session ID can be controlled by configuration options in the Web server. In environments that use WebSphere Edge Server with multiple HTTP servers, you must use an affinity
mechanism when SSL session ID is used as the session tracking mechanism.

When the SSL session ID is to be used as the session tracking mechanism in a clustered environment, either cookies or URL rewriting must be used to maintain session affinity. The cookie or rewritten URL contains session affinity information that enables the Web server to properly route requests back to the same server once the HTTP session has been created on a server. The SSL ID is not sent in the cookie or rewritten URL but is derived from the SSL information.

The main disadvantage of using SSL ID tracking is the performance hit of using SSL. If you have a business requirement to use SSL, then this would be a good choice. If you do not have such a requirement, it is probably a good idea to consider using cookies instead.

SessionInspectServlet

WebSphere Application Server Ships com.ibm.ws.webcontainer.httpsession.SessionInspectServlet servlet that you can use to investigate what content is stored in HttpSession of your application. The SessionInspectServlet will tell you

1. Names of the session attributes


2. Size of the data in session attribute


3. If the attribute is serializable or not

You might want to use this when you start getting NotSerializableException or you run into performance issue due to size of data stored in session.

You can follow these steps to add SessionInspectorServlet to your web application

1. Add Session Inspector servlet to web.xml file of your web application
   

   
   <servlet>
    <display-name>SessionInspectServlet</display-name>
    <servlet-name>SessionInspectServlet</servlet-name>
    <servlet-class>com.ibm.ws.webcontainer.httpsession.SessionInspectServlet</servlet-class>
   </servlet>
   <servlet-mapping>
    <servlet-name>SessionInspectServlet</servlet-name>
    <url-pattern>/SessionInspectServlet</url-pattern>
   </servlet-mapping>
   

   
   You dont have to include any jars in your web application. If you search for SessionInspectServlet class you will notice that it is part of WebSphere/AppServer/plugins/com.ibm.ws.webcontainer_2.0.0.jar, which is websphere runtime so you can use that class without including it in your web application
   


2. Install and start your web application on server


3. Access the SessionInspectorServlet by going to /webcontext/SessionInspectorServlet url
   
   This is the output that i get for my webapplication, i am storing object of Contact class in session that does not implement Serializable interface and a String, String is serializable
   

Shared Session Context

The Servlet specification defines session scope at the Web Application level, session information stored by one web application cannot be shared by other web applications even in the same enterprise application.WebSphere Application Server provides an IBM extension, that allows sharing the session information to be shared among web applications within an enterprise application. This option is offered as an extension to the application deployment descriptor.


In order to try this scenario i tried creating a Simple SessionContextSampleEAR. It has two .war files and each .war file has one servlet each. I am setting the session attribute in one servlet and accessing it in another and it works.

You can enalbe shared session context using RAD or IBM WAS Toolkit during the application assembly phase like this




Now if you check ibm-application-ext.xmi file in you .ear files META-INF folder you will see that value of sharedSessionContext attribute is set to true like this


<applicationext:ApplicationExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:applicationext="applicationext.xmi" xmi:id="ApplicationExtension_1250896346141" sharedSessionContext="true">
<application href="META-INF/application.xml#Application_ID"/>
</applicationext:ApplicationExtension>

Session Management

1. Application Server: This is the default level. Configuration at this level is applied to all Web modules within the server.


2. Application: Configuration at this level is applied to all Web Modules within the web application


3. Web Modules: Configuration at this level is applied only to the web application

The level at which you set a property decides the scope at which that property is assigned. You get the Session management link at all three levels and when you click on that link you will get a screen like this

WebSphere Application Server has set of Session properties that you can set at either of the following three levels


WAS allows you to set following session management properties

• Session tracking mechanism: WebSphere Application server provides following three mechanism to implement the session tracking
  
  
  
  • Enable SSL ID Tracking:Specifies that session tracking uses Secure Sockets Layer (SSL) information as a session ID. Enabling SSL tracking takes precedence over cookie-based session tracking and URL rewriting.
  
  
  • Enable Cookies: Specifies that session tracking uses cookies to carry session IDs. If cookies are enabled, session tracking recognizes session IDs that arrive as cookies and tries to use cookies for sending session IDs. If cookies are not enabled, session tracking uses Uniform Resource Identifier (URL) rewriting instead of cookies (if URL rewriting is enabled).
    Enabling cookies takes precedence over URL rewriting. Do not disable cookies in the session management facility of the application server that is running the administrative application because this action causes the administrative application not to function after a restart of the server. As an alternative, run the administrative application in a separate process from your applications. Click Enable cookies to change these settings.
    
  
  
  • Enable URL Rewriting: Specifies that the session management facility uses rewritten URLs to carry the session IDs. If URL rewriting is enabled, the session management facility recognizes session IDs that arrive in the URL if the encodeURL method is called in the servlet.
  
  

Maximum in-memory session count: The meaning differs depending on whether you are using in-memory or distributed sessions. For in-memory sessions, this value specifies the number of sessions in the base session table. Use the Allow overflow property to specify whether to limit sessions to this number for the entire session management facility or to allow additional sessions to be stored in secondary tables. For distributed sessions, this value specifies the size of the memory cache for sessions. When the session cache has reached its maximum size and a new session is requested, the session management facility removes the least recently used session from the cache to make room for the new one.

Session Timeout: Specifies how long a session can go unused before it is no longer valid. Specify either Set timeout or No timeout. Specify the value in minutes greater than or equal to two. The value specified in a Web module deployment descriptor file takes precedence over the administrative console settings. However, the value of this setting is used as a default when the session timeout is not specified in a Web module deployment descriptor. Note that to preserve performance, the invalidation timer is not accurate to the second. When the write frequency is time based, ensure that this value is least twice as large as the write interval.

Security Integration: Specifies that when security integration is enabled, the session management facility associates the identity of users with their HTTP sessions

Serialize session access: determines if concurrent session access in a given
server is allowed.

Overwrite session management, for enterprise application and Web module level only, determines whether these session management settings are used for the current module, or if the settings are used from the parent object.