WebSphere Reverse Investor: Back to basics: Session failover

In each column, "WebSphere contrarian investors" will answer questions, provide guidance and discuss the underlying topics associated with WebSphere products, often giving proven recommendations that contradict popular perceptions.

Knowledge consolidation Time

Over the past few weeks, I've spent a lot of time providing in-house training for technical sales experts on the newly released Ibm®websphere®application Server V7. Part of the training has been allocated to basic materials to back up the basics to provide background information to novice WebSphere application Server and to provide knowledge consolidation for veterans. It turns out that quite a number of "veteran" experts have discovered the value of my experiments and lectures-more than I expected. True: You will never be able to reach a state where you don't need to be reminded of your basic knowledge.

For the same reason, I decided to introduce a basic aspect of WebSphere application Server in this column: Session failover. More accurately, it should be: Session failover and my recommendation for failover.

Why do you use HttpSession?

Hypertext Transfer Protocol (hypertext Transfer Protocol,http) is the foundation of WEB applications and is a stateless protocol. States are typically managed by setting up cookies, and browsers track cookies between requests, providing a mechanism for associating a series of unique requests from a given user to a "conversation" or stream. Unfortunately, using cookies to manage the state is quite difficult. Fortunately, the Java servlet API uses the HttpSession interface to provide a solution for this disadvantage, which allows the Servlet to associate a given user with a series of requests by using session objects for session tracking and state management between multiple request invocations.

HttpSession: When and how to use

Unfortunately, session-specific data can be stored in session objects. I say "sorry" because HttpSession is usually ultimately used as an application cache, which is not exactly what it was intended for. Although it is not wrong to use a session to associate a request from a user, using a session as an application cache can easily lead to many application practices that put pressure on multiple aspects of the application environment. For example, a client has a MB (not a typographical error) session object that they are saving to a database, and the result is:

Poor database performance because the database performed hundreds of updates to the (Super) session object in the database table.

Network performance is dropping because updates are pushed from the application server to the database server.

Application servers are frequently garbage collected because the heap that should be used for application processing is consumed by session objects that are associated with each user; For example, 200 users X MB = MB (or 0.5 GB) Size dialog Objects! Even a 1GB or 2GB heap is too small for storing so many application state data.

This improper use of HttpSession also leads to concerns about the loss of information in the session object, because recreating the information stored in it is time-consuming.

As you might have guessed, my advice is not to use HttpSession as an application cache, but to use HttpSession to correlate multiple user requests. It is best to keep the httpsessions as small as possible. However, in some applications, this recommendation is not followed, so you may need some sort of "quick" way to change the application to reduce the saved content with minimal impact. In this case, I recommend using the techniques listed in the article titled to improve HttpSession performance using intelligent serialization to minimize the amount of information actually stored in the session object, thereby minimizing the amount of information that your application must handle when you choose to use session distribution.

Session distribution: When and how to use

The Servlet APIs are ready to distribute session objects. In other words, you can take a copy of the session object so that the failure of an application server instance does not cause the application state of a given user to be lost-or, more precisely, multiple users, because there may be multiple users using the WebSphere application Server The HttpSession Association mechanism is associated with a given application server instance.

My preferred workaround is to rely on the HTTP Server Plug-in Association to "pin" a user to an application server, although it does mean that stopping the application server JVM will cause the HttpSession object to be lost. The advantage of this is that when an application fails or stops, it is not necessary to distribute session objects to prepare for HttpSession object failover. The obvious downside is that users will lose all application state and will need to log back in and re-create the state, which may be unacceptable to your application or business requirements. I will mention that I have worked with a number of clients who actually agree with this and use it as their standard practice.

In other words, maybe you really can't stand someone having to log on again and re-create the HttpSession object from scratch. Perhaps this is because you have unfortunately chosen to use HttpSession as the application cache, or for some other reason. In any case, WebSphere application Server Network Deployment (hereinafter called Network Deployment) provides two mechanisms for session distribution: Distributed Replication Services (distributed Replication Service,drs) and database persistence. My recommendations for the network deployment session distribution mechanism are the same as those stated in the previous column, namely, database persistence.

Another alternative mechanism for session distribution is the WebSphere EXtreme Scale, formerly known as the ObjectGrid component of the WebSphere Extended deployment. The WebSphere eXtreme Scale provides a memory-based replication mechanism that is independent of the runtime of the application server. Therefore, you can use the WebSphere eXtreme Scale to share application state (cache) between different applications running on different application server runtimes. For HttpSession, WebSphere EXtreme Scale provides a Servlet filter that can overwrite any Java Platform, Enterprise Edition EAR file HttpSession Realize. It is easy to install this filter into the EAR through the scripts provided in the WebSphere EXtreme Scale.

I want to add that if you are actually using HttpSession as an application cache, WebSphere EXtreme Scale is likely to be a better alternative than providing a mechanism for session distribution in network deployment. This is because the WebSphere eXtreme Scale is intended to be used as a distributed application cache, and HttpSession is never intended for this purpose, although HttpSession is used effectively in the way described above, network deployment The distributed session options in are efficient and scalable.