March 22, 2011, 11:35 p.m.
posted by franni
Managing Session State
Using servlets in complex applications introduces interesting challenges to the developer. Possibly the biggest challenge is to maintain the application state for users as they make multiple trips into your application. We call the information collected and maintained during these trips session data. Session data is temporary and only for use across a set of linked pages; transaction data is placed in permanent storage.
Session data is often converted into transaction data within the application. For instance, when a user chooses to save profile information, or checks out a shopping cart, the temporary session data becomes permanent. Correctly maintaining this type of information creates challenges and is a constant problem in servlet- and JSP-based applications. Figure shows where the resolution to this problem fits in our architectural road map.
The first challenge comes from the HTTP protocol used for communication between the Web browser and the Web server. As discussed in Chapter 6, this protocol is based upon a request/response model and is stateless. That is, once a request is submitted from the client browser to a Web server, and the server acts upon the request and sends a response back to the browser, the server forgets about the request and the requestor. There is no intrinsic method in the protocol for holding state information about the transaction itself. After a transaction is complete, data not explicitly stored during the interaction is lost.
The second part to this problem comes from the way servlets live in the application server. On a particular application server, a single instance of each servlet class handles all GET and POST requests for its particular URL. In this environment, each HTTP request is handled on a unique thread running the service() method of that instance. Since each servlet instance is a shared resource, you can't effectively store the client session data in the instance variables of the servlet itself because data stored by one thread could be overwritten by another. Remember that a servlet is an object shared by multiple simultaneous threads.
You could attempt to use synchronization and an in-memory hash table to manage instance data for each user, but only at a significant cost in effort and performance. The implication to the developer in this case is that there should be no maintenance of state information in the servlet itself, or, more directly, no instance variables—only local variables and parameters!
If instance variables are used there is no guarantee that the state will be reliable at any given time. In this chapter, we will explore the most common approaches to storing session data, and look at the configuration options that are available within WAS.