Session Tracking

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. Overview

In a narrow sense, 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.

2. Session Tracking Structure

This section describes the basic structure of session tracking.

Since this section provides only a very simplified description of session tracking, users who are unfamiliar with the concept needs to 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 architecture of web engine with session
Session Parts in the JEUS Web Engine Structure

An HTTP session is a sequence of tasks related to HTTP requests from the same client (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.

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 which is referred to as 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.

3. Session Tracking Behaviors

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

3.1. Session Tracking Behaviors 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.

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.

  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 session cookie and the response are sent to the client’s browser, and 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 making a second request to the same web engine using previously stored session
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.

3.2. Session Tracking in Clustered Environments

Session Tracking Behaviors in Web Engines describes session tracking in a simple scenario where a client, web server, and web engine are connected. In a real-world 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 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 Session Servers. The following section discusses these issues and their solutions in detail.

The first and the second issues deal with the same problem, but use different approaches to resolve it, sticky session routing and session server.

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.

  1. A client makes an initial request to the 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 without session routing client session is lost in a clustered environment
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 a first client request results in a route enabled session containing a container id
Adding Web Engine ID to the Session Cookie

  1. A client makes an initial request to the 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.

JEUS 6 uses the actual engine ID. In JEUS 9, the ID is encoded.

The following diagram shows the sticky session routing process.

figure session routing in action
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.

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 Configuring Web Server Load Balancing in JEUS Web Engine Guide.

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 controls routing only. 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.

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 storing session data and session id in a separate session server
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 session cookie and the response are sent to the client’s 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 session data is always fetched from central session server instead of from container internal memory
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. However, they can use the session server as a common storage where session data is saved and retrieved for session sharing.

Conceptually, we assume here that the engine A and engine B are separate storages while the session server provides a common storage. But the web engines A and B could also be common storages themselves like the session server. Here, the 'common' storage means that they can be accessed via network, or other interfaces.

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 centralized 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 Distributed Session Server Configuration.

JEUS 9 supports its own centralized session server as well as Redis and Hazelcast as session servers. For information about how to configure them, refer to Distributed Session Server Configuration.

Mixed Mode

Mixed mode is a combination of session routing and session server. The following table discusses the benefits and limits of session routing and session server.

Session Routing Session Servers

Pros

Fast 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.

Cons

Session 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.

4. Session Tracking Modes

A session tracking mode can be selected in Servlet 4.0.

  • 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 approach used for URL rewriting in JEUS 6. 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.

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 scope for the distributed session configuration. The scope must be configured for session sharing between different contexts. For more information about the configuration, refer to Distributed Session Server Configuration.

6. Configuring Session Tracking

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

  • Sticky Session Routing

    Session routing is supported by default and thus requires no additional configuration.

    Encoding information can be additionally configured.

    Value Description

    BASE64

    Encodes information by using the BASE64 rule.

    Used to avoid exposing engine or domain information through the session ID.

    BASE64_WITHOUT_PADDING

    Encodes information by using the BASE64 rule without PADDING ("=").

    Used to avoid exposing engine or domain information through the session ID.

    RAW

    Does not encode information.

    This is used for debugging because it is difficult to determine which engine sent the request by using encoded information, or under a circumstance where no security issues exist even though an engine name is exposed.

  • Session Server Configuration

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

  1. For detailed information about sticky session routing and session servers, refer to Distributed Session Server Configuration.

  2. Session tracking can also be configured using jeusadmin, a console tool. Refer to set-sessionstorage-scope-session-config in JEUS Reference Guide.

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 is how to configure sessions in domain.xml.

  1. In domain.xml, go to [domain] > [server] > [web-engine] > [session-config].

    These settings define the common session configuration used in the web engine. Settings can be overridden by the context, which has a higher configuration priority than the web engine.

    <session-config>
    <timeout>10</timeout>
    <max-session-count>-1</max-session-count>
    <reload-persistent>false</reload-persistent>
    <tracking-mode>
        <cookie>true</cookie>
        <url>false</url>
        <ssl>false</ssl>
    </tracking-mode>
    <session-cookie>
        <cookie-name>JSESSIONID</cookie-name>
        <url-cookie-name>jsessionid</url-cookie-name>
        <version>0</version>
        <path>/</path>
        <max-age>-1</max-age>
        <secure>false</secure>
        <http-only>true</http-only>
        <same-site>Disable</same-site>
        <partitioned>false</partitioned>
    </session-cookie>
</session-config>

The following describes the configuration tags.

  • Tracking Mode

    Set the method of transferring sessions for session tracking. The following describes three modes of session tracking, which can be used all at once. If not specified, only the cookie-based session tracking will be used by default.

  • 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.

    Value Description

    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.

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

    Cookie

    Cookie-based session tracking.

    • true: Uses cookie-based session tracking. (Default value. Recommended)

    • false: Does not use cookie-based session tracking. This may affect session maintenance.

    Url

    URL rewriting-based session tracking.

    • true: Uses URL rewriting for session tracking.

    • false: Does not use URL rewriting for session tracking. (Default value)

    Ssl

    SSL-based session tracking.

    • true: Transfers sessions only via SSL during session tracking. This may not be fully functional.

    • false: Transfers sessions not only via SSL, but also any other types of connections during session tracking. (Default value)

    Cookie Name

    Name 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 setting 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. The default value is -1, and the unit is in seconds.

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

    Secure

    Option to use a 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.

    SameSaite

    Option to use a security mode that prevents the session ID cookies from being used for an unintended request (Cross-site request forgery, CSRF).

    • Disable: Does not add the same-site cookie, and complies with the web browser’s policy.

    • None: Allows the cookie to be sent in cross-site requests.

    • Strict: Disallows the cookie from being sent in cross-site requests (preventing the CSRF attack).

    • Lax: Only allows cross-site requests that are relatively safe against the CSRF attack. For more information, refer to relevant specifications.

    Comment

    Description that help users understand the purpose of the cookie.

    This is not supported in the Netscape Version 0 cookies.

If the scope is configured for inter-context session sharing, the session timeout setting uses the scope’s session timeout value.

Each configuration item cannot be changed dynamically, thus the server needs to be restarted to apply the changes.

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 Session Cluster Modes and Distributed Session Server Configuration respectively.

7. Tuning Session Tracking

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.

8. Monitoring Sessions

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

Sessions can be monitored by using the following method.

  • Using the console tool

    For information about monitoring sessions using the console tool, refer to show-web-statistics and list-session in JEUS Reference Guide.