General Design Issues for Web Applications

Web servers and servlets are by their nature multithreaded. As a result, a single servlet object normally has multiple response threads running in it at any point in time. A simple but important consequence is the prohibition on putting request or response information into the instance fields of the servlet. In general, servlets use their instance fields very lightly or not at all. If the servlet class defines an instance field, the programmer must realize that the instance field is shared among multiple response threads and that access to it must be protected by the synchronized keyword. An alternative is to use servlets that implement the javax.servlet.SingleThreadModel marker interface, but this alternative is not recommended for performance reasons.

Even though Web applications normally avoid using the member fields in a servlet instance, Web applications have two easy ways to communicate between the multiple methods or components that are processing a single request. Both of these methods avoid sharing objects between response threads. First, the methods within a servlet can use parameters and return values to communicate. Second, two components, such as a servlet and a JSP, can communicate by using the getAttribute and setAttribute methods in the javax.servlet.ServletRequest object.

Although most Web application programmers understand the multithreaded nature of servlets and how to deal with it, the HTTP protocol raises some design issues that are not widely understood. First, the Web application may need to respond to multiple concurrent requests from the same client. If a page takes more than a few seconds to render, there is a fair chance that the user will click again, causing the same request to be made by his browser. As a result, a servlet may be responding to multiple, redundant requests from the same client. If the Web application uses the javax.servlet.http.HttpSession object, which is shared among all of the response threads serving a single client, then there must be synchronization to make the Web application's code thread-safe for the objects stored in the session. Second, the user may inadvertently make multiple requests when all he wants is a single action. If the user is checking out a shopping cart of merchandise, the chances are very high that he does not want to purchase the contents twice even if he clicks twice on the Proceed button. As a result, at least some of the actions taken by the servlet must be idempotent, a Latin word meaning that the response to a request occurs only once, even when there are two or more redundant requests. Third, the browser allows the user to make requests in any order. The browser's Forward, Back, and Bookmark buttons allow the user to jump around in the request logic in ways that can be nonsensical.

Although it is incidental to the purpose of this book, the rental Web application has code to handle these design issues. The SessionLock class is the primary tool to address the thread-safety and idempotency issues. The SessionLock class, which is found in the com.ysoft.jdo.book.rental.servlet.util package, queues up multiple requests from one client. Although the control servlet eventually responds to all of the client's requests, it responds to them one at a time. At the same time, the SessionLock class allows multiple requests from different clients to proceed concurrently. The servlet collaborates with the SessionLock class to skip redundant actions while always displaying redundant results. Because the Web application has no way to know which response the browser will display when the user makes redundant requests, the Web application must give the same response to all redundant requests.

The rental Web application responds appropriately to client requests that are out-of-sync with the client's known state. Before responding to the client's request, the rental Web application examines the client's state to determine whether the requested action can be performed. If not, it performs a reasonable action that the client's state allows. Issuing an error report is always a possibility when the client's request cannot be satisfied, but in the case of the rental application, displaying the available rentals is usually preferable.