Table of Contents
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).
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.
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.
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.
-
A client connects to the web server.
-
The client sends a stateless HTTP request.
-
The client receives a response.
-
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.
This section describes session tracking in JEUS web engines and in clustered environments.
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.
-
A client makes an initial request to the web server.
-
The web server sends the request to the web engine.
-
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.
-
The response data and session cookie are sent to the web server.
-
The response data and session cookie are sent to the client's browser, and then the HTTP connection is disconnected.
-
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.
-
The client sends another request to the same web server by attaching the session cookie previously received from the web browser.
-
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.
-
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.
-
The response data and session cookie are sent to the web server.
-
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.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.
-
How will the request that includes the session cookie be sent to the web engine that first requested it?
-
How can HTTP sessions that were created in one engine be used in other engines so that every engine can process restricted requests?
-
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.
-
The client makes an initial request to a web server.
-
The web server arbitrarily selects a web engine to send the request to. Web engine A is selected in this example.
-
The request is sent to Web engine A.
-
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.
-
The web engine sends the response, and the session cookie is returned to the web server.
-
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.
-
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.
-
The web server accepts the request and arbitrarily selects one of the two web engines. In this example, Web engine B is selected.
-
The request and the session cookie are sent to Web engine B.
-
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.
-
The client makes an initial request to a web server.
-
The web server arbitrarily selects a web engine. Web engine A is selected in this example.
-
The request is sent to Web engine A.
-
Web engine A creates an HTTP session and a session ID cookie, and inserts the web engine ID (EID) into the cookie.
-
The response and session cookie are returned to the web server.
-
The response and session cookie are returned to the browser.
-
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.
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.
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.
-
A client sends a request to the web server.
-
The web server arbitrarily selects Web engine A in the cluster to handle the request.
-
The web server sends the request to Web engine A.
-
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.
-
When the request is handled, the web engine saves the HTTP session object and the session ID in the session server.
-
The response data and session cookie are sent to the web server.
-
The response data and session cookie are sent to the browser, and the HTTP connection is disconnected.
-
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.
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 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.
A session tracking mode can be selected in Servlet 3.1.
-
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 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 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.
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".
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.
-
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.
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.
-
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].
-
Click [Lock & Edit] to switch to the configuration mode.
-
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].
The following describes the configuration items.
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.
-
Advanced Session Configuration
-
Session tracking mode. All three modes can be used concurrently. Cookie tracking is used by default.
Item Description 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.
-
-
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.
-
-
After the configuration is complete, click [Apply Changes] to apply the changes.
-
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.
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.
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.
The number of sessions can be determined through basic monitoring of the created sessions.
Session monitoring can be done using the following methods.
-
Using WebAdmin
For information about monitoring sessions in WebAdmin, refer to the "Web Engine Monitoring" section in JEUS Web Engine Guide. "1.4. Management Tools".
-
Using the console tool
For information about monitoring sessions using the console tool, refer to JEUS Reference Book. "4.2.8.34. show-web-statistics" and JEUS Reference Book. "4.2.9.2. list-session".