Session Management Part-1
WebSphere Application Server Session Management
Session support allows a Web application developer to maintain stateinformation across multiple user visits to the application.
We will cover below points
1.HTTP session management
2.Session manager configuration
3.Session identifiers
4.Local sessions
5.General properties for session management
6.Session affinity
7.Persistent session management
1.HTTP session management:
When an HTTP client interacts with a servlet, the state information associated with a series of client requests is represented as an HTTP session and identified by a session ID. Session management is responsible for managing HTTP sessions, providing storage for session data, allocating session IDs, and tracking the session ID associated with each client request through the use of cookies or URL rewriting techniques.
2.Session manager configuration:
Session management in WebSphere Application Server can be defined at the following levels:
a)Application server:
This is the default level. Configuration at this level is applied to all Web modules within the server.
b)Application:
Configuration at this level is applied to all Web modules within the application.
c)Web module:
Configuration at this level is applied only to that Web module.
Session management properties:
1) Overwrite session management: for enterprise application and Web module level only, determines whether these session management settings are used for the current module, or if the settings are used from the parent object.
2) Session tracking mechanism: lets you select from cookies, URL rewriting, and SSL ID tracking. Selecting cookies will lead you to a second configuration page containing further configuration options.
3) Maximum in-memory session count: lets you specify the maximum number of sessions to keep in memory and whether to allow this number to be exceeded, or overflow.
4) Session timeout: specifies the amount of time to allow a session to remain idle before invalidation.
5) Security integration: specifies that the user ID be associated with the HTTP session.
6) Serialize session access: determines if concurrent session access in a given server is allowed.
7) Distributed environment settings: determines how to persist sessions (memory-to-memory replication or a database) and set tuning properties. Memory-to-memory persistence is only available in a Network Deployment distributed server environment.
Accessing session management properties
You can access all session management configuration settings using the administrative console. Application server session management properties To access session management properties at the application server level, from the administrative console, do the following steps:
1. Select Servers → Server Types → WebSphere application servers.
2. Click the application server.
3. In the Container Settings section of the Configuration tab, click Session management.
4. WebSphere Application Server V7: Session Management
Application session management properties To access session management properties at the application level, from the administrative console, do the following steps:
1. Click Applications → Application Types → WebSphere enterprise applications.
2. Click the application name to open its configuration page.
3. In the Web Module Properties section of the Configuration tab, click Session management. Web module session management properties To access session management properties at the Web module level, from administrative console, do the following steps:
1. Click Applications → Application Types → WebSphere enterprise applications.
2. Click the application.
3. In the Modules section of the Configuration tab, click Manage Modules.
4. Click the Web module.
5. In the Additional Properties section, click Session Management.
3)Session identifiers:
WebSphere session support keeps the user’s session information about the server. WebSphere passes the user an identifier known as a session ID, which correlates an incoming user request with a session object maintained on the server.
Session tracking mechanism:
WebSphere supports three approaches to tracking sessions:
a)SSL session identifiers (deprecated)
b)Cookies
c)URL rewriting
It is possible to select all three options for a Web application. If you do this:
SSL session identifiers are used in preference to cookie and URL rewriting. Cookies are used in preference to URL rewriting.
Note: If SSL session ID tracking is selected, we recommend that you also select cookies or URL rewriting so that session affinity can be maintained. The cookie or rewritten URL contains session affinity information enabling the Web server to properly route a session back to the same server for each request.
To set or change the session mechanism type, do the following steps:
1. Open the session management properties for the application server, enterprise application, or Web module.
2. Select the session tracking mechanism (Figure 1).
3. Click OK.
4. Save and synchronize the configuration changes.
5. Restart the application server or the cluster.
b) Cookies
Cookie support to pass the user’s identifier between WebSphere and the user. WebSphere Application Server session support generates a unique session ID for each user, and returns this ID to the user’s browser with a cookie. The default name for the session management cookie is JSESSIONID. See Figure 2.
Cookie settings:
To configure session management using cookies, do the following steps from the administrative console:
1. Open the Session Manager window at your preferred level.
2. Click the box for Enable Cookies as the session tracking mechanism. See Figure 1.
3. If you would like to view or change the cookies settings, select the Enable Cookies hot link. The following cookie settings are available:
– Cookie name:
The cookie name for session management should be unique. The default cookie name is JSESSIONID. However, this value can be configured for flexibility.
– Restrict cookies to HTTPS sessions:
Enabling this feature restricts the exchange of cookies only to HTTPS sessions. If it is enabled, the session cookie’s body includes the secure indicator field.
– Cookie domain:
This value dictates to the browser whether or not to send a cookie to particular servers. For example, if you specify a particular domain, the browser will only send back session cookies to hosts in that domain. The default value in the session manager restricts cookies to the host that sent them.
*Note: The LTPA token/cookie that is sent back to the browser is scoped by a single DNS domain specified when security is configured. This means that all application servers in an entire WebSphere Application Server domain must share the same DNS domain for security purposes.
-Cookie path:
The paths on the server to which the browser will send the session
tracking cookie.
Specifying a value restricts the paths to which the cookie will be sent. By restricting paths, you can keep the cookie from being sent to certain URLs on the server.
c)URL rewriting
WebSphere also supports URL rewriting for session ID tracking.
The servlet or JSP developer has to write extra code is a major
drawback over the other available session tracking mechanisms.
URL rewriting limits the flow of site pages exclusively to dynamically generated pages, such as pages generated by servlets or JSPs. WebSphere inserts the session ID into dynamic pages, but cannot insert the user’s session ID into static pages, .htm, or .html.
Therefore, after the application creates the user’s session data, the user must visit dynamically generated pages exclusively until they finish with the portion of the site requiring sessions. URL rewriting forces the site designer to plan the user’s flow in the site to avoid losing their session ID.
URL rewriting configuration:
When you select URL rewriting, an additional configuration option, Enable protocol switch rewriting, is available. This option defines whether the session ID, added to a URL as part of URL encoding, should be included in the new URL if a switch from HTTP to HTTPS or from HTTPS to HTTP is required.
4.Local sessions:
The in-memory, local session cache. The local session cache keeps session information in memory and local to the machine and WebSphere Application Server where the session information was first created.Local session management does not share user session information with other clustered machines. Users only obtain their session information if they return to the application server. Most importantly, local session management lacks a persistent store for the sessions it manages. A server failure takes down not only the WebSphere instances running on the server, but also destroys any sessions managed by those instances. WebSphere allows the administrator to define a limit on the number of sessions held in the in-memory cache from the administrative console settings on the session manager. This prevents the sessions from acquiring too much memory.
in the Java VM associated with the application server. The session manager also allows the administrator to permit an unlimited number of sessions in memory. If the administrator enables the Allow overflow setting on the session manager, the session manager permits two in-memory caches for session objects. The first cache contains only enough entries to accommodate the session limit defined to the session manager, 1000 by default.
The second cache, known as the overflow cache, holds any sessions the first cache cannot accommodate, and is limited in size only by available memory. The session manager builds the first cache for optimized retrieval, while a regular, un-optimized hash table contains the overflow cache.
Important: If you enable overflow, the session manager permits an unlimited number of sessions in memory. Without limits, the session caches might consume all available memory in the WebSphere instance’s heap, leaving no room to execute Web applications. For example, here are two scenarios under
which this could occur:
1. The site receives greater traffic than anticipated, generating a large number of sessions held in memory.
2. A malicious attack occurs against the site where a user deliberately manipulates their browser so the application creates a new session repeatedly for the same user.
If you choose to enable session overflow, the state of the session cache should be monitored closely.
Note: Each Web application will have its own base, or primary, in-memory session cache, and with overflow allowed, its own overflow, or secondary, in-memory session cache.
General properties for session management
a) Mximum in-memory session count:This field specifies the maximum number of sessions to maintain in memory. two sessions are there i.e. local persistent sessions.
For local sessions, this value specifies the number of sessions in
the base session table.
For persistent sessions, this value specifies the size of the general cache.This value determines how many sessions will be cached before the session manager reverts to reading a session from the database automatically. Session manager uses a least recently used (LRU) algorithm to maintain the sessions in the cache.
b)Allow overflow:
Choosing this option specifies whether to allow the number of sessions in memory to exceed the value specified in the maximum in-memory session count field. If Allow overflow is not checked, then WebSphere limits the number of sessions held in memory to this value.
For local sessions, if this maximum is exceeded and Allow overflow is not checked, then sessions created thereafter will be dummy sessions and will not be stored in the session manager.
Note: Allowing an unlimited amount of sessions can potentially exhaust system memory and even allow for system sabotage. Someone could write a malicious program that continually hits your site, creating sessions, but ignoring any cookies or encoded URLs and never utilizing the same session from one HTTP request to the next.
c)Session timeout:
If you select Set timeout, when a session is not accessed for this many minutes it can be removed from the in-memory cache and, if persistent sessions are used, from the persistent store. this Performance tunning directly influences the amount of memory consumed by the JVM™ in order to cache the session information.
Note:If you select No timeout, a session will be never removed from the memory unless explicit invalidation has been performed by the servlet. This can cause a memory leak when the user closes the window without logging out from the system.
d)Security integration:
When security integration is enabled, the session manager associates the identity of users with their HTTP sessions.
Note: Do not enable this property if the application server contains a Web application that has form-based login configured as the authentication method and the local operating system is the authentication mechanism. It will cause authorization failures when users try to use the Web application.
e)Serialize session access:
This option is available to provide serialized access to the session in a given JVM. This ensures thread-safe access when the session is accessed by multiple threads.This option is not recommended when frame-sets are used heavily because it can affect performance.
SESSION MANAGEMENT PART-2 Link
https://webspherehome.blogspot.com/2018/06/session-affinity-in-clustered.html
Comments
Post a Comment