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.

Difference between War, Jar & Ear

1.JAR : JAVA Archives and it allows aggregating many files into One.It usually hold java classes in lib.

JAR files (Java ARchive) allows aggregating many files into one, it is usually used to hold Java classes in a library. i.e. Math.jar 

(file with a .jar extension)

2.War(web archive)   This is Web Application archive which contains basic web application like servlet, jsp, html. This can be run on simple tomcat server

WAR files are similar to JAR files, except that they are specifically for web applications made from Servlets, JSPs, and supporting classes(file with a .war extension)

3.Ear (: Enterprise Archives)

An EAR file is an enterprise application deployed to an application server like WebLogic, WebSphere, JBOSS, etc. It might contain WARs, JARs, etc. 

EAR = WAR(Web module) + JAR(can be EJB module or application client module)

files with a .ear extension




// Virtual Host  :host several domains with a single web server

Diff Between Heap dump And Thread dump

Diff Between Heap dump And Thread dump

Thread Dump:
When we trigger a thread dump on an application server, all active thread information will be dumped into file which is normally known as thread dump. In this dump file, we can get information about thread like active thread, hung thread, dead lock, runnable and inactive thread info.

Command to generate thread dump: kill -3 PID_OF_SERVER

When our application server reports the thread hung conditions in SystemOut.log file then we generate thread dump to analyze the reason behinds thread hungs. We are generally having thread hung situation when any threads coming to system becomes unresponded.

When Websphere Application Server detects that a thread has been active longer than the time defined by the thread monitor threshold then it write below error code in SystemOut.log file:

• WSVR0605W: Thread threadname has been active for hangtime and may be hung. There are totalthreads threads in total in the server that may be hung.

Where: threadname is the name that appears in a JVM thread dump, hangtime gives an approximation of how long the thread has been active and totalthreads gives an overall assessment of the system threads.

If the above thread gets released by itself then we get below entry in our log file:

• WSVR0606W: Thread threadname was previously reported to be hung but has completed. It was active for approximately hangtime. There are totalthreads threads in total in the server that still may be hung.

Heap Dump:
Heap dump is a text file which keeps record of all objects in the java heap. It contains the information like size and address of all objects, as well as the addresses of all objects that it references.

Before generating the heap dump, we need to enable the garbage collection to get only live objects information in dump.

By Default, whenever OutOfMemoryException occurs Websphere application Server create heap dump in profile’s home directory.

Heap dump is nothing but a snap shot of our JVM’s Heap memory, so here we can have all active java objects and their activities which object doing what and how much memory it is occupying.