How to configure HTTP Session in Websphere?

 How to configure HTTP Session in Websphere?

1)    Login to admin console.

2)    Go to servers --> Server Types --> Websphere application servers

3)    Click on Server

4)    Click on Session Management

5)    You can change the setting from the above mentioned screen.

6)    Click on Apply/Ok to save the setting.

7)    You will come to following screen. Click Save.

Session management properties:

With one exception, the session management properties that you can set are the same at each configuration level:

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.

Choosing a session tracking mechanism

WebSphere supports three approaches to tracking sessions:

1.SSL session identifiers (deprecated)

2.  Cookies

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

Steps to do this

1. Open Admin console.
2. Open the session management properties for the application server, enterprise application or Web module.
3. I am doing here for Application server.
4. Go to Servers à Servers types à Websphere application servers

5. Click on servers1
6. You will come to following page. Click on Session management from the left panel.

7. Here you can check all the three, or what ever you want. As shown in following figure.

Note:

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. For best performance, define a primary cache of sufficient size to hold the normal working set of sessions for a given Web application server.

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.

8. Click Ok and Save.

9. Restart the Application server or cluster to reflect the changes.

It's Done....
Amit Kumar Roy