Chapter 6 Session Managers

Session objects maintain state and user identity across multiple page requests over the normally stateless HTTP protocol. A session persists for a specified period of time, across more than one connection or page request from the user. A session usually corresponds to one user, who might visit a site many times. The server can maintain a session either by using cookies or by rewriting URLs. Servlets can access the session objects to retrieve state information about the session.

This chapter describes sessions and session managers, and has the following sections:

• Introducing Sessions

• Using Sessions

• Session Managers

Introducing Sessions

The term user session refers to a series of user application interactions that are tracked by the server. Sessions are used for maintaining user specific state, including persistent objects such as handles to database result sets and authenticated user identities, among many interactions. For example, a session can be used to track a validated user login, followed by a series of directed activities for a particular user.

The session itself resides in the server. For each request, the client transmits the session ID in a cookie or, if the browser does not allow cookies, the server automatically writes the session ID into the URL.

The Sun Java System Web Server 7.0 supports the servlet standard session interface, called HttpSession, for all session activities.

This section includes the following topics:

• Sessions and Cookies

• Sessions and URL Rewriting

• Sessions and Security

As of Sun Java System Web Server 7.0, form-login sessions are no longer supported. You can use single sign-on sessions instead.

Sessions and Cookies

A cookie is a small collection of information that can be transmitted to a calling browser, which retrieves it on each subsequent call from the browser so that the server can recognize calls from the same client. A cookie is returned with each call to the site that created it, unless it expires.

Sessions are maintained automatically by a session cookie that is sent to the client when the session is first created. The session cookie contains the session ID, which identifies the client to the server on each successive interaction. If a client does not support or allow cookies, the server rewrites the URLs where the session ID appears in the URLs from that client.

You can configure whether and how sessions use cookies. For more information on related elements in the sun-web.xml file, see session-properties Element and cookie-properties Element.

Sessions and URL Rewriting

You can also configure whether sessions use URL rewriting. For more information, see the sun-web.xml element session-properties Element.

Sessions and Security

The Sun Java System Web Server 7.0 security model is based on an authenticated user session. Once a session has been created, the application user is authenticated if authentication is used and is logged into the session.

Additionally, you can specify that a session cookie is only passed on an HTTPS secured connection , so the session can only remain active on a secure channel.

For more information about security, see Chapter 8, Securing Web Applications.

Using Sessions

To use a session, first create a session using the HttpServletRequest method getSession(). Once the session is established, examine and set its properties using the provided methods. If desired, set the session to time out after being inactive for a defined time period, or invalidate it manually. You can also bind objects to the session, which store them for use by other components.

This section includes the following topics:

• Creating or Accessing a Session

• Examining Session Properties

• Binding Data to a Session

• Invalidating a Session

Creating or Accessing a Session

To create a new session or gain access to an existing session, use the HttpServletRequest method getSession(), as shown in the following example:

HttpSession mySession = request.getSession();

getSession() returns the valid session object associated with the request, identified in the session cookie that is encapsulated in the request object. Calling the method with no arguments creates a session that is associated with the request if one does not already exist. Additionally, calling the method with a Boolean argument creates a session only if the argument is true.

The following example shows the doPost() method from a servlet that only performs the servlet's main functions if the session is present. Note that the false parameter to getSession() prevents the servlet from creating a new session if one does not already exist

public void doPost (HttpServletRequest req, HttpServletResponse
res) throws ServletException, IOException
 {
        if ( HttpSession session = req.getSession(false) ) {
           // session retrieved, continue with servlet operations
        }
        else{
           // no session, return an error page
        }
}

         

The getSession() method should be called before anything is written to the response stream.

For more information about getSession(), see the Java Servlet 2.4 specification.

Examining Session Properties

Once a session ID has been established, use the methods in the HttpSession interface to examine session properties. Use the methods in the HttpServletRequest interface to examine request properties that relate to the session.

The following table shows the methods used to examine session properties.

For example:

String mySessionID = mySession.getId();
     if ( mySession.isNew() ) {
         log.println(currentDate);
        log.println("client has not yet joined session " + mySessionID);
     }

         

The following table shows the methods used to examine servlet request properties.

For example:

if ( request.isRequestedSessionIdValid() ) {
        if ( request.isRequestedSessionIdFromCookie() ) {
           // this session is maintained in a session cookie
         }
        // any other tasks that require a valid session
      } else {
        // log an application error
      }

         

Binding Data to a Session

You can bind objects to sessions to make them available across multiple user interactions.

The following table shows the HttpSession methods that provide support for binding objects to the session object.

Binding Notification with HttpSessionBindingListener

Some objects require you to know when they are placed in or removed from a session. To obtain this information, implement the HttpSessionBindingListener interface in those objects. When your application stores or removes data with the session, the servlet engine checks whether the object being bound or unbound implements HttpSessionBindingListener. If it does, the Sun Java System Web Server 7.0 notifies the object under consideration, through the HttpSessionBindingListener interface, that it is being bound into or unbound from the session.

Invalidating a Session

Direct the session to invalidate itself automatically after being inactive for a defined time period. Alternatively, invalidate the session manually with the HttpSession method invalidate().

Invalidating a Session Manually

To invalidate a session manually, call the following method:

session.invalidate();

All objects bound to the session are removed.

Setting a Session Timeout

Session timeout is set using the session-timeout element in the web.xml deployment descriptor file. For more information, see the Java Servlet 2.4 specification.

Session Managers

Sun Java System Web Server 7.0 provides the following session management options, which are described in this section:

• memory, the default session manager

• file, a provided manager that store sessions on the file system

• IWS60, a provided session manager that allows backward compatibility with any custom session managers you may have created using Sun Java System Web Server 7.0

• MMAP (UNIX Only), a provided persistent memory map (mmap) file-based session manager that works in both single-process and multi-process mode

memory Option

The memory is the default memory based session manager.

Enabling memory

You can specify memory explicitly to change its default parameters. To do so, edit the sun-web.xml file for the web application as in the following example. Note that persistence-type must be set to memory.

<sun-web-app>
         ...
        <session-config>
           <session-manager persistence-type=”memory”>
              <manager-properties>
                 <property name="reapIntervalSeconds" value="20" />
              </manager-properties>
           </session-manager>
            ...
        </session-config>
        ...
</sun-web-app>

For more information about the sun-web.xml file, see Chapter 9, Deploying Web Applications.

Manager Properties for Memory

The following table describes manager-properties properties for the memory based session manager.

file Session Manager

The file is another file-system-based session manager provided with Sun Java System Web Server 7.0. For session persistence, file can use a file to which each session is serialized. You can also create your own persistence mechanism.

Enabling the file Session Manager

You can specify file explicitly to change its default parameters. To do so, edit the sun-web.xml file for the web application as in the following example. Note that persistence-type must be set to file.

<sun-web-app>
        ...
        <session-config>
           <session-manager persistence-type=”file”>
              <manager-properties>
                 <property name=reapIntervalSeconds value=20 />
              </manager-properties>
              <store-properties>
                 <property name=directory value=sessions />
              </store-properties>
           </session-manager>
           ...
        </session-config>
        ...
</sun-web-app>

For more information about the sun-web.xml file, see Chapter 9, Deploying Web Applications.

Manager Properties for file

The following table describes manager-properties properties for the file session manager.

IWS60 Session Manager

The IWS60 session manager ensures backward compatibility with any 6.0 session managers that you may have created.

IWS60 works in both single-process and multi-process mode. It can be used for sharing session information across multiple processes possibly running on different machines.

The MaxProcs directive in the magnus.conf file determines whether the server is running in single-process or multi-process mode. If the value of MaxProcs is higher than 1 and no session manager is configured, then by default the session manager used is the IWS60 with file-based persistence. The Maxprocs is deprecated in Web Server 7.0.

For session persistence, IWS60 can use a database or a distributed file system (DFS) path that is accessible from all servers in a server farm. Each session is serialized to the database or distributed file system. You can also create your own persistence mechanism.

If Sun Java System Web Server 7.0 is running in single-process mode, then by default, no session persistence mode is defined and therefore sessions are not persistent.

If Sun Java System Web Server 7.0 is running in multi process mode, sessions are persistent by default. If a persistence mode is not defined, IWS60 uses a DFS.

Multi-process mode is supported only on UNIX platforms. All multi process mode features of IWS60 are ignored on Windows.

Enabling IWS60

You can enable IWS60 to change its default parameters. You can also enable IWS60 for a particular context if the server is running in single-process mode. To do so, edit the sun-web.xml file for the web application as in the following example. The persistence-type must be set to s1ws60.

<sun-web-app>
   ...
   <session-config>
    <session-manager persistence-type=”s1ws60”>
     <manager-properties>
      <property name=”classname” value=”com.iplanet.server.http.
                                       session.IWSSessionManager”/>
      // other manager-related properties
     </manager-properties>
    </session-manager> 
     ...
   </session-config>
   ...
</sun-web-app>

In the case of persistent sessions:

<sun-web-app>
		...
		<session-config/>
		 <session-manager persistence-type=”s1ws60”>
		  <manager-properties>
		   <property name=”classname” value=”com.iplanet.server.http.
                                       session.IWSSessionManager”/>
   	// other manager-related properties
    </manager-properties>
    <store-properties>
     <property name=”classname” value=”com.iplanet.server.http.
                                               session.FileStore”/>
     <property name=”directory” value=”<directory name to store the_
persistant_sessions>”/>
       // other store-related properties
     </store-properties>
    </session-manager> 
   	  ...
   </session-config>
  	 ...
		</sun-web-app>

For more information about the sun-web.xml file, see Chapter 9, Deploying Web Applications.

Manager Properties for IWS60

The following table describes manager-properties properties for the IWS60 session manager.

Prior to using JdbcStore, you must create the table in which the session information is stored. The name of the table is specified by the table parameter, and the table’s four columns are specified by the accessTimeColumn, timeOutColumn, sessionIdColumn, and valueColumn parameters.

FileStore, JdbcStore, IWSSessionManager, IWSHttpSession, IWSHttpSessionManager, and SessionDataStore have been deprecated in Sun Java System Web Server 7.0.

Source Code for IWS60

The IWS60 session manager creates an IWSHttpSession object for each session. The source files for IWSSessionManager.java and IWSHttpSession.java are in the install_dir/lib directory. The source code files for IWSSessionManager.java and IWSHttpSession.java are provided, so you can use them as the starting point for defining your own session managers and session objects.

IWSSessionManager extends IWSHttpSessionManager. The class file for IWSHttpSessionManager is in the JAR file webserv-rt.jar in the directory install_dir/lib. The IWS60 implements all of the methods in IWSHttpSessionManager that need to be implemented, so you can use IWSSessionManager as an example of how to extend IWSHttpSessionManager. When compiling your subclass of IWSSessionManager or IWSHttpSessionManager, be sure that the JAR file webserv-rt.jar is in your compiler’s classpath.

The JdbcStore.java and FileStore.java source files and the source file for the parent class, SessionDataStore.java, are provided so you can modify the session persistence mechanism of IWS60. These files are also located in the install-dir/lib directory.

The session-timeout parameter specified in web.xml will not be effective when IWS60 is used.

MMap Session Manager (UNIX Only)

MMap is a persistent memory map (mmap), file-based session manager that works in both single-process and multi-process mode.

The MaxProcs directive in the magnus.conf file determines whether the server is running in single-process or multi-process mode. The Maxprocs is deprecated in Web Server 7.0.

Enabling MMap

You can enable MMap to change its default parameters. You can also enable MMap for a particular context if the server is running in single-process mode. To do so, edit the sun-web.xml file for the web application as in the following example. Note that persistence-type must be set to mmap.

<sun-web-app>
        ...
        <session-config>
            <session-manager persistence-type=”mmap”>
              ...
          </session-manager>
           ...
        </session-config>
        ...
</sun-web-app>

For more information about the sun-web.xml file, see Chapter 9, Deploying Web Applications.

Manager Properties for MMap

The following table describes manager-properties properties for the MMap session manager.

MMap can only store objects that implement java.io.Serializable.