Session Management In WAS..

Session Management In WAS !!

Session is nothing but a mechanism to keep track of user’s activity over period of time. It simply maintains a user state’s information.

SESSION TRACKING MECHANISM:

We have mainly three approaches to track the sessions in IBM WebSphere:

• SSL session identifiers

• Cookies

• URL rewriting

SSL ID TRACKING:

In this mechanism, we track the HTTP session ID by using SSL session information.

SSL tracking is only used for the IBM HTTP Server and SUN ONE Web Server but if we are using SSL tracking in cluster environment then we must also be enabled cookies or URL rewriting to get session affinity facility.

COOKIES:

Whenever user requests for any resources, one session gets created with unique session ID which returns to user’s browser with a cookie. The default name for the session management cookie is JESSIONID.

The browser holds the cookie and returns it to the server whenever user makes a subsequent request.

URL REWRITING:

In URL rewriting, session identifier get stored in the page returned to the user.

WebSphere encodes the session identifier as a parameter on URLs that have been encoded programmatically by the Web application developer. Infect in this particular tracking, developer plays a crucial role to implement this mechanism in their coding itself.

URL rewriting limits the flow of site pages only to dynamically generated pages.

  

SESSION AFFINITY:

Session affinity enables the Web server to properly route requests back to the same server once the HTTP session has been created on a server. In a clustered environment, any HTTP requests associated with an HTTP session must be routed to the same Web application in the same JVM.

In session affinity, each server ID is appended to the session ID. When an HTTP session is created, its session ID is passed back to the browser as part of cookie or URL encoding. When the browser makes further requests, the cookie or URL encoding will be sent back to the Web server. The Web server plug-in examines the HTTP session ID in the cookie or URL encoding, extracts the unique ID of the cluster member handling the session, and forwards the request.

PERSISTENT SESSION:

Persistent session is concept which provides failover to session affinity. In persistent session implemention, if one cluster member get fails then also user can continue to use session information from another cluster member.

In this management, WebSphere places session objects in a persistent store which is accessible by all cluster members. When one cluster member get fails then other cluster member keep continue to serve user by using same session from persistent session store by only changing cache ID and server ID in cookie.

We can configure the session persistence in two way:

• Database persistence

• Memory-to-memory session state replication using the data replication service available in distributed server environments.