Chapter 1. Session Tracking

Table of Contents

1.1. Overview
1.2. Session Tracking Structure
1.3. Session Tracking
1.3.1. Session Tracking in Web Engines
1.3.2. Session Tracking in Clustered Environments
1.4. Session Tracking Mode
1.5. Sharing Sessions between Contexts
1.6. Session Tracking Configuration
1.6.1. Session Configuration
1.6.2. Session Server Configuration
1.7. Session Tracking Tuning
1.8. Monitoring

This chapter describes the basic concepts of session tracking and the definitions of session, session ID, session cookie, and URL rewriting. This chapter will also describe the implementation and configuration of session tracking in a more complex clustered server environment (distributed environment).

1.1. Overview

Session tracking is an action that finds a requested session. In a clustered environment, depending on the scope of session tracking support, session tracking is classified into two types, session tracking through routing and through a session server.

Note

Versions earlier than JEUS v7.0 use both central and distributed session servers, but JEUS v7.0 and later versions use only distributed session servers.

1.2. Session Tracking Structure

This section describes the basic structure of session tracking.

Note

Since this section provides only simple description of session tracking structure, users unfamiliar with it should refer to other documents about servlet and session tracking.

The following diagram shows session tracking and the web engine components related to session management.

[Figure 1.1] Partial JEUS Web Engine Structure

Partial JEUS Web Engine Structure


An HTTP session is a sequence of tasks related to HTTP requests from the same client (e.g., web browser). When multiple clients send requests over HTTP, since there is no unique "Client ID" in the header, web servers cannot differentiate the clients.

Web servers cannot track user requests because HTTP is a stateless and connectionless protocol.

Note

Web servers are also a part of session tracking.

The following shows the steps for processing an HTTP request.

  1. A client connects to the web server.

  2. The client sends a stateless HTTP request.

  3. The client receives a response.

  4. The HTTP connection is disconnected.

A client ID or continuous session is not included in the HTTP protocol. When the HTTP connection is disconnected or the response is sent, all information about the request is discarded. Thus, an HTTP request is not suitable for complex web applications where users are continuously sending related requests.

To overcome this problem, a special string called the session ID is added to each HTTP request. When a client makes a request for the first time, this unique ID is created and sent to the client. The session ID is attached to each request for any subsequent requests from the same client. This allows the web engine to identify the source of each request and maintain conversational state during transaction processing thereby supporting sessions for stateless HTTP protocols.

The session ID is sent either as a cookie or through URL rewriting, which automatically adds the session ID as a parameter in the URL. The session ID can also be stored in a hidden field of an HTML form.

1.3. Session Tracking

This section describes session tracking in JEUS web engines and in clustered environments.

1.3.1. Session Tracking in Web Engines

JEUS web engine supports URL rewriting and cookies, which are enabled by default, for session tracking. The cookie that contains the session ID is called a session cookie.

In web engines, a single session is an instance of the HTTP session class. The instance is connected to the session ID of a session cookie or the URL parameter from URL rewriting. By default, HTTP session objects exist in the web engine that created them. They contain user data such as preferences or list of products for purchase.

Note

Both URL rewriting and cookies can be used for session tracking. The session ID is included in the URL link of an HTML page, but session cookies are included separately in the cookie header.

Session cookies are used when a client requests a resource that is managed by the JEUS web engine. The following describes the process of a web engine creating a session cookie.

[Figure 1.2] Creating a Session Cookie

Creating a Session Cookie

  1. A client makes an initial request to the web server.

  2. The web server sends the request to the web engine.

  3. The web engine creates an HTTP session object for the client and a session cookie that contains the session ID of the HTTP session. The session ID is used to retrieve the HTTP session object for any subsequent requests from the client.

  4. The response data and session cookie are sent to the web server.

  5. The response data and session cookie are sent to the client's browser, and then the HTTP connection is disconnected.

  6. The session cookie that contains the session ID is saved in the client's browser.

Now, the client can include the session cookie when sending requests to the same web server. The web engine identifies the client by the cookie's session ID and can retrieve the client's HTTP session object.

The following is a description of this process.

[Figure 1.3] Sending a Second Request using the Session ID

Sending a Second Request using the Session ID

  1. The client sends another request to the same web server by attaching the session cookie previously received from the web browser.

  2. The web server receives the request with the session cookie and just like in the first request, sends the request to the same web server.

  3. The web engine receives the request and session cookie. Then, it finds the HTTP session object corresponding to the session ID of the session cookie from its own memory. Then, the web engine uses the HTTP session data to process the request.

  4. The response data and session cookie are sent to the web server.

  5. The HTTP response is sent to the web browser and the HTTP connection is disconnected. The session cookie has to be included in the response only when the initial connection is created.

1.3.2. Session Tracking in Clustered Environments

"1.3.1. Session Tracking in Web Engines" describes session tracking in a simple situation where a client, web server, and web engine are connected. In a real environment, there are many situations where this type of simple structure is not sufficient for session tracking. Load balancing and clustering must be implemented in order to handle a large volume of requests. For detailed information about clustering, refer to JEUS Web Engine Guide. "2.4. Configuring Web Server Load Balancing".

Extra caution is required when forming and configuring session mechanisms in web server clusters. There are three major issues to consider when managing sessions in a distributed cluster.

  1. How will the request that includes the session cookie be sent to the web engine that first requested it?

  2. How can HTTP sessions that were created in one engine be used in other engines so that every engine can process restricted requests?

  3. How is session data backed up in case the web engine goes down due to a failure?

The first issue can be handled using sticky session routing, and the rest can be handled using a session server. The following section discusses the problems and their solutions in detail.

Note

The first and the second issues deal with the same problem, but they are each resolved using a different method, sticky session routing or session servers.

Sticky Session Routing

Sticky session routing attaches the ID of the engine where the session was created or where the session is saved to the end of the session ID in a clustered environment. Because the engine ID is included in the cookie, the web server can use the ID to identify and request for the cookie. This increases the efficiency of retrieving a session from the web engine.

The following is an example of processing a client request when two web engines, A and B, are connected to a single web server.

[Figure 1.4] Using Session ID Cookie to Create a Session Using Two Web Engines

Using Session ID Cookie to Create a Session Using Two Web Engines


  1. The client makes an initial request to a web server.

  2. The web server arbitrarily selects a web engine to send the request to. Web engine A is selected in this example.

  3. The request is sent to Web engine A.

  4. Web engine A creates an HTTP session object and returns a session ID cookie with the response. This ID is used when the HTTP session object handles future requests from the same client.

  5. The web engine sends the response, and the session cookie is returned to the web server.

  6. The session cookie and the response are sent to the client's browser, and the HTTP connection is disconnected.

The first request is processed successfully, but a critical error occurs when the same client makes a second request.

[Figure 1.5] Deleting a Session When Sticky Session Routing is not Used

Deleting a Session When Sticky Session Routing is not Used


  1. The client makes another request to the same web server. This time, the session cookie that was returned for the first request is sent with the request.

  2. The web server accepts the request and arbitrarily selects one of the two web engines. In this example, Web engine B is selected.

  3. The request and the session cookie are sent to Web engine B.

  4. Web engine B receives the request and the session cookie. The web engine attempts to retrieve the HTTP session for the cookie, but there is no corresponding object. Web engine B cannot maintain the client session and either creates a new session or returns an error message, neither of which is recommended.

As shown in the previous figure, load can be distributed by increasing the number of engines that perform the same service. However, there is the problem of not being able to find the session information.

To resolve this problem, each request must be properly routed to the session of the web engine that originally created the HTTP session object. Such routing can be accomplished by adding the web engine ID to the session cookie. The following diagram shows this process.

[Figure 1.6] Adding Web Engine ID to the Session Cookie

Adding Web Engine ID to the Session Cookie


  1. The client makes an initial request to a web server.

  2. The web server arbitrarily selects a web engine. Web engine A is selected in this example.

  3. The request is sent to Web engine A.

  4. Web engine A creates an HTTP session and a session ID cookie, and inserts the web engine ID (EID) into the cookie.

  5. The response and session cookie are returned to the web server.

  6. The response and session cookie are returned to the browser.

  7. The session cookie, which includes the web engine ID (EID), is saved in the browser.

Note

JEUS v6.x uses the actual engine ID, but in JEUS v8.0 the ID is encoded.

The following diagram shows the sticky session routing process.

[Figure 1.7] Sticky Session Routing

Sticky Session Routing


In the second request, the web server finds the session cookie and the engine ID (EID). The web server routes the request to the original web engine, which has the HTTP session object.

Note

Web servers other than WebtoB require the mod_jk module to be installed so that the engine IDs can be recognized. This function is built-in in WebtoB.

For detailed information about the installation of mod_jk, refer to JEUS Web Engine Guide. "2.4. Configuring Web Server Load Balancing".

To use sticky session routing, every web server must be connected to every web engine. This is because when a load balancer is used, the session might get disconnected if the web server that received the request cannot connect to the correct web engine. If the load balancer independently supports session routing, it is not necessary that every web server be connected to every web engine. For example, if WebtoB is used with the load balancer, then session routing is available even if the servers are not completely connected to each other.

Sticky session routing is only in charge of routing. If the routing operates effectively, it prevents the creation of duplicate sessions as well as duplicate saves, thereby improving performance. However, the routing does not force a request to be sent to a specific web engine. If a target engine has a failure or is under heavy load, a request is sent to another engine. That is, a complete cluster environment cannot be configured just with sticky session routing.

Session Servers

Session servers are more powerful than sticky session routing.

When using session servers, it is not necessary to connect every web engine to every web server in a cluster. Session data in a cluster is backed up by session servers, and so even if a web engine fails, the session data is saved and another web engine can handle the request.

The following diagram shows what happens when a web engine fails. In this scenario, all session data in the web engine is lost.

[Figure 1.8] Web Engine Failure

Web Engine Failure


To maintain the sessions when a web engine fails, session servers are added to the cluster. When session servers are used, a client's first HTTP request is handled as in the following figure.

[Figure 1.9] Session Servers - First Request

Session Servers - First Request


  1. A client sends a request to the web server.

  2. The web server arbitrarily selects Web engine A in the cluster to handle the request.

  3. The web server sends the request to Web engine A.

  4. The web engine creates an HTTP session object and a session cookie. This ID is used to retrieve the HTTP session object for future requests from the same client.

  5. When the request is handled, the web engine saves the HTTP session object and the session ID in the session server.

  6. The response data and session cookie are sent to the web server.

  7. The response data and session cookie are sent to the browser, and the HTTP connection is disconnected.

  8. The browser saves the session cookie.

Even if Web engine B is later selected by the web server to handle Client A's request or if Web engine A fails, the session data can be retrieved from the session server.

[Figure 1.10] Session Servers - Second Request

Session Servers - Second Request


As shown in the previous figure, the session server's role is common storage. Web engines A and B are separate storage mediums and are constructed in such a way that they cannot access each other's data. They can use the session server as a common storage where session data is saved and retrieved for session sharing.

To provide safer session data storage, backup servers are used for fault tolerance. The backup server is automatically selected from the cluster and is automatically updated when a server fails or a new server is added.

Session servers provide the benefit of being able to continuously maintain sessions even if a web engine fails. Like central session server in previous versions of JEUS, session servers contain separate storage and interface that can be accessed by any web engine. This allows sessions to persist even during failure.

However, a central session server cannot maintain high performance in a large scale clustered environment due to the overhead caused by centrally storing all web engines' sessions. Also, a single server solution is not appropriate for a distributed environment.

For this reason, JEUS uses distributed session server. Distributed session servers are designed to produce increased performance in clustered environments.

In a distributed session server, each web engine has its own session server. It uses session routing by default although session routing is not required it helps increases performance. Like session servers, the session data backup can be configured which allows sessions to persist even if the web engine fails.

A distributed session server is automatically included in a server cluster. If a server cluster is configured, the contexts of all servers included in the cluster share and maintain sessions through a distributed session server without separate configurations. For detailed information about distributed session server configuration, refer to "2.10.3. Distributed Session Server Configuration Details".

Mixed Mode

Mixed Mode is a combination of session routing and session server. The following table discusses the pros and cons of session routing and session server.

 Session RoutingSession Servers
ProsFast because it accesses the session objects in the web engine.All session objects are saved in the session server. Session data is not lost when a web engine fails.
ConsSession data is lost when a web engine fails.Session data must be saved and retrieved from the session server, which is slower than session routing.

Mixed mode provides the advantages of both methods. When the methods are combined, session objects exist on every session server and in the web engine that created them. The web engine only retrieves or modifies session objects from the session server when it needs them. Mixed mode uses only about half the network bandwidth of using only session servers. Mixed mode also guarantees the safety of all session data. Mixed mode session management is recommended for clustered environments.

1.4. Session Tracking Mode

A session tracking mode can be selected in Servlet 3.1.

  • Cookie Mode

    This mode uses cookies to track sessions.

    Cookies are closely connected to the browser and this is the most common way to track sessions. However, since cookies are dependent on browsers, sessions may not be maintained in situations where cookies are not used. Session tracking is possible as long as cookies are used according to their specifications.

  • URL Mode

    URL Rewriting mode is used when cookies cannot be used or when the browser does not support cookies.

    This is the same method used for URL rewriting in JEUS v6.x. This saves session data in the URL without using cookies. This allows sessions to be maintained without using a web browser that supports cookies.

    To use this mode, a special tag is required in the jeus-web-dd.xml deployment descriptor. When the <tracking-mode><url> tag is used, the session ID is saved using URL Rewriting which allows session tracking across multiple domains.

  • SSL Mode

    SSL Mode is restricted to SSL connections, and is recommended for situations where a restricted transfer of sessions is desired.

    This mode can be used to store secure data in a session. If SSL mode is used, sessions can only be transferred through an SSL connection.

1.5. Sharing Sessions between Contexts

Sessions are usually managed by the same context, but they can be shared among different contexts.

Using session servers does not mean that all sessions are shared. To share session data between contexts, configure the Shared session setting.

Note

The Shared setting must be configured to share session data. For detailed information, refer to"1.6.1. Session Configuration".

1.6. Session Tracking Configuration

The following configurations are required to use session routing or session server.

  • Sticky Session Routing Configuration

    Session routing is supported by default and requires no additional configuration. Encoding information can be additionally configured.

    ItemDescription
    BASE64

    Encodes information by using the BASE64 rule in order not to expose engine or domain information through a session ID.

    RAW

    Does not encode information. This is used for debugging because it is difficult to determine an engine that sent a request by using encoded information, or when there is no security issues even though an engine name has been exposed.

  • Session Server Configuration

    To use distributed session servers, the servers must be in a cluster.

Note

1. For detailed information about sticky session routing and session servers, refer to "2.9. Basic Configuration for a Session Cluster".

2. Session tracking can also be configured using jeusadmin, a console tool. Refer to JEUS Reference Book. "4.2.9.5. modify-session-configuration" for description about the configuration commands.

1.6.1. Session Configuration

Many items can be configured for session management. All aspects of a session such as whether to share session objects, session cookie configuration, and timeout can be configured.

The following are the steps for configuring sessions in WebAdmin.

  1. Click [Servers] on the left menu to go to the server list screen.

    Click the desired server in the server list to go to the server configuration screen.

    On the configuration screen, click [Engine] > [Web Engine] > [Session Config].

  2. Click [Lock & Edit] to switch to the configuration mode.

  3. The following Session Config screen is divided into basic and advanced options. These items define the common session configuration used in the web engine. The configuration can be overridden by the context, which has a higher configuration priority than the web engine. Configure each item and click [OK].

    [Figure 1.11] Session Configuration - Basic Information

    Session Configuration - Basic Information

    The following describes the configuration items.

    ItemDescription
    Timeout

    Expiration period of sessions created by the server.

    The session timeout is usually configured in web.xml, the web application configuration. If the session timeout is already configured in web.xml, this setting is ignored. The session timeout setting in web.xml has the highest priority.

    The units are in minutes. The default value is 30.

    Max Session Count

    Maximum number of sessions to maintain in memory. If the number of sessions exceeds the maximum number of sessions, an error will occur.

    Since the number of sessions for an application must not have any influence on session creation for another application, this maximum number needs to be set for each application.

    The default value is -1, which means that sessions can be created infinitely.

    Shared

    Option to share and use the session objects that were created in the current context with other contexts (by the same user in another context).

    For non-clustered environments, sessions are shared within the same application. In clustered environments, the scope is unlimited.

    The default value is false.

    Note

    If the session is shared between multiple contexts by configuring the Shared setting, JEUS web engine uses the session timeout configuration of the context that originally created the session.

    The following diagram shows the Advanced Options section of the Session Config screen.

    [Figure 1.12] Session Configuration - Advanced Options

    Session Configuration - Advanced Options

    • Advanced Session Configuration

      ItemDescription
      Reload Persistent

      Option to persist session object properties when servlet context is modified and reloaded. Normally in such case all properties are deleted. If not set, the default value is used.

      • true: Properties of session objects persist after reloading.

      • false: Properties of session objects are deleted after reloading (default value).

    • Tracking Mode

      Session tracking mode. All three modes can be used concurrently. Cookie tracking is used by default.

      ItemDescription
      Cookie

      Use cookies to track sessions.

      • true: Use cookies to track sessions. Using the default value is recommended.

      • false: Don't use cookies to track sessions. Sessions might not function correctly.

      Url

      Use URL Rewriting to track sessions.

      • true: Use URL Rewriting.

      • false: Don't use URL Rewriting. This is the default value.

      Ssl

      Use SSL when tracking sessions.

      • true: Session information is only sent over SSL. Sessions might not function correctly.

      • false: Session information is sent even over non-SSL connections. This is the default value.

    • Session Cookie

      The standard way to track sessions is to use session cookies in the client response.

      This configures the cookies in the HTTP header of the response from the web engine. Although cookies are usually created in the web engine, this configuration can be used to create specific cookie data.

      The following describes each configuration item.

      ItemDescription
      Cookie NameName used instead of the standard "JSESSIONID". This is a string, and the default value is JSESSIONID.
      Version

      Version of the cookie ID. Options are:

      • 0: Netscape cookie (default value).

      • 1: RFC cookie.

      Domain

      Domain name sent with the session cookie. Cookies can be accessed only from this domain. The domain name must start with ".". For more detailed information, refer to RFC-2109.

      This is a string. If not set, the cookie's domain information is omitted.

      Path

      URL(string) path in the domain where the session cookie is sent. Cookie is sent when there is a request from this URL in the specified domain.

      If the path is configured as "/examples" and the domain is configured as ".foo.com", the client will only send the cookie to the server when the request location is "www.foo.com/examples". For more detailed information, refer to RFC-2109.

      • If not set: An appropriate path in the web engine is selected.

      • If set: This value is always included in the cookie.

      If this is set to a value other than the root path "/", take caution when setting this value by considering session sharing characteristics of the applications.

      Max Age

      Session cookie expiration. When a cookie expires, it is deleted by the client and is no longer sent.

      (Default value: -1, Unit: second)

      If set to the default value, the cookie expires when the browser closes according to the browser's life cycle.

      Secure

      Option to use secure http connection.

      • true : Cookies are only sent over HTTPS.

      • false : Cookies can be sent over non-HTTPS connections (default value).

      Http Only

      HttpOnly property of the session ID cookie. The HttpOnly property is a new function in Servlet 3.0 that prevents cookies from being used by scripts.

      • true : Session cookies can only be used in HTTP requests (default value).

      • false : Session cookies can be used by scripts.

      Comment

      Description that help users understand the purpose of the cookie.

      This is not supported in the Netscape Version 0 cookies.

  4. After the configuration is complete, click [Apply Changes] to apply the changes.

  5. When the changes have been applied, the results will be displayed on the screen as in the following figure. Not all items on the Session Config screen are dynamically configured, which means that they are applied when the server restarts.

    [Figure 1.13] Session Configuration - Result

    Session Configuration - Result

1.6.2. Session Server Configuration

A cluster is required to use session servers in the domain structure. Configure the servers that are participating in the cluster in WebAdmin to use session servers without configuring the contexts. For detailed information about clustering and configuration of distributed session servers, refer to "2.8. Session Cluster Modes" and "2.10.3. Distributed Session Server Configuration Details" respectively.

1.7. Session Tracking Tuning

The following guidelines provide the best performance in a clustered environment.

  • For better performance and stable operation, always use sticky session routing and session servers together.

  • Properly configure and tune web servers.

  • Use distributed session servers for sites that are overloaded with user requests.

1.8. Monitoring

The number of sessions can be determined through basic monitoring of the created sessions.

Session monitoring can be done using the following methods.