ONJava.com: Handling Multiple Submits

Published on ONJava.com (http://www.onjava.com/)
http://www.onjava.com/pub/a/onjava/2003/04/02/multiple_submits.html
See this if you're having trouble printing code examples

Handling Multiple Submits

by Al Saganich
04/02/2003

The primary purpose of the web site of today is to display dynamic content. At some point, the user sends input to a web application to be processed and the results returned. Typically, back-end operations occur quickly enough and all is well, from the user perspective. Occasionally, more time-consuming processing must take place, resulting in delays. Eventually the delay may become so noticable that the user believes he has made a mistake and either gives up or resubmits his request.

The problem of handling operations that run for long periods of time isn't a new one. Java provides a robust threading mechanism that can create background tasks. Additionally, with the arrival of the EJB 2.0 specification, Message-based EJBs (so-called MDBs) can be used to perform background operations. However, remember that these mechanisms are designed to handle asynchronous operations. You start a thread or background process, and at some later point you are notified or must check for a result, all asynchronously.

What about slightly long-running applications that are synchronous in nature but still take a noticable amount of processing? Imagine the scenario where a concert goer logs on to her favorite web site to order tickets for a show that's just gone on sale. (Recent sales of Bruce Springsteen tickets come to mind!) Under normal circumstances, the site performs fine and our would-be concertgoer purchases her tickets and is on her way. However, when a heavy load occurs, the server slows down, frustrating the user (who thinks her purchase request failed), so she hits the submit button again and again. Unfortunately, each hit of the submit button ends up ordering another set of tickets.

There are many ways to handle this type of scenario. The most obvious is to prevent the user from submitting the same request repeatedly in the first place. Another might be to somehow track that a user has previously submitted a request and revert to the previously-submitted action. The figure below shows the output from a simple servlet that processes the input as it arrives and assigns a ticket number to each request.

Processing Simple Submissions

Figure 1: Processing simple submissions

The primary and most effective way to handle the multiple submits problem is to prevent it from happening. ConcertTickets.html shows the underlying HTML for a simple form that captures the name of a concert and submits it to a servlet to order tickets. The process works perfectly when the web site responds quickly. However, if the web site bogs down and the submit is not processed quickly enough, the user gets frustrated and resubmits. The processing shown below results.

Listing 1: ConcertTickets.html

01: <html>
02: <head><title>Online Concert Tickets</title></head>
03:
04: <center><h1>Order Tickets</h1></center>
05: 
06: <form name="Order" action="./SimpleOrder" method="GET">
07: <table border="2" width="50%" align="center"  bgcolor="CCCCCC">
08: <tr><td align="right" width="40%">Concert:  </td>
09: <td width="60%"><input type="text" name="Concert" value=""></td></tr>
10:
11: <tr><td colspan="2" align="center">
12: <input type="submit" name="btnSubmit"
13: value="Do Submit"></td></tr>
14: </table>
15: </form>
16: </body>
17: </html>

Figure 2: Repeated submissions

Preventing Multiple Submits

The simplest way to handle the multiple submit problem is to prevent it from happening. Below is a revised version of our form, which includes a small amount of JavaScript. The embedded JavaScript remembers if the submit button was previously pressed. On a resubmit, an alert pops up and the form is not submitted again. We can short-circuit the normal submit processing by adding an onClick attribute to the submit button. Every time the button is clicked, the onClick code executes. In our case, this results in the JavaScript checksubmitcount() being called. However, just calling a function doesn't really help. If we did no more then add the onClick, we'd get our popup alert box every time the submit button was pressed, and then immediately the submit would happen. The user would be alerted that she made a mistake, but the request would be sent anyway. This is an improvement only from the user perspective. The end result to the server is the same: multiple submits.

Listing 2: Concert2.html

01: <html>
. . .<!-- repeated code removed //-->
12: <input type="button" name="btnSubmit"
13: value="Do Submit"
14: onClick="checksubmitcount();"></td></tr>
15: </table>
16: </form>
17:
18: <script language="javascript">
19: <!--
20: var submitcount = 0;
21: function checksubmitcount()
22: {
23: 	submitcount++;
24: 	if (1 == submitcount )
25: 	{
26: 		document.Order.submit();
27: 	}
28: 	else
29: 	{
30:  	if ( 2 == submitcount)
31:  		alert("You have already submitted  this form");
32:  	else
33:  		alert("You have submitted this form"
34:  		+ submitcount.toString()
35:  		+ " times already");
36: 	}
37: }
38: //-->
39: </script>
40: </body>
41: </html>

We can solve the problem by going one step further and subtly changing the way our page works. Sharp readers might have noticed one additional change to the form. The type of our button, line 12, originally submit, is now replaced by button. The look and feel of the page is identical. However, the default action associated with the form, shown on line 6, to invoke the servlet, is no longer automatic. We can now programmatically choose to submit the form to our server and our problem is solved--or is it?

Handling Multiple Submits

Listing 2 was certainly an improvement, but we've still got a ways to go. A number of issues still could go wrong. What if the user pushes the back button and starts over? What if his browser has JavaScript disabled or the browser cannot handle the processing? We can still solve the problem, but instead of preventing multiple submits, we need to handle them on the back end, via the form-processing servlet.

In order to understand how to solve the multiple submit problem, we must first understand how servlets work with respect to sessions. As everyone knows, HTTP is inherently a stateless protocol. In order to handle state, we need some way for the browser to associate the current request with a larger block of requests. The servlet session provides us a solution to this problem. The HttpServlet methods doGet() and doPost() use two specific parameters: HttpServletRequest and HttpServletResponse. The servlet request parameter allows us to access what is commonly referred to as the servlet session. Servlet sessions have mechanisms for accessing and storing state information.

What exactly is a servlet session? A servlet session is a number of things, including:

A set of state managed by the web server and represented by a specific identifier shared by all requests for a given client.
A place to store state data, defined, at least for HttpServlets, via the HttpSession interface.

Before we look at how to solve our problem with a server-side solution, we need to understand the servlet session lifecycle. As with EJBs and other server side entities, servlet sessions go through a defined set of states during their lifetime. The figure below shows the lifecycle of a servlet session. Servlets move through three distinct states: does not exist, new, and not new or in-use.

Figure 3: Servlet session lifecycle

Initially, a servlet session does not exist. A session starts here or returns to this state for a number of reasons. Most likely, the user has never accessed the state before or the session was invalidated because the user left the site (timed out) or explicitly left (logged out).
Sessions move from does not exist to new when the session is first created. The distinction between new and not new is important because of the fact the HTTP is stateless. According to the servlet specification, sessions cannot move to not new (from being a prospective session to an actual session) until the client returns the session to the server. Thus a session is new because the client does not yet know about it or the client decides not to join the session.
When the session is returned to the server via a cookie or URL re-writing (more on that in a moment), then the session becomes in use or not new.
Continued use of the session, via its various get and set methods, result in the session remaining in use.
Transitions 5 and 6 happen when a session times out due to inactivity or a session is explictly invalidated. Application servers handle timeouts in a variety of ways. BEA WebLogic Server allows the application deployer the ability to set the session timeout via a special deployment descriptor (weblogic.xml) packaged with the web application.

NOTE: Careful use of getSession(true)

At first glance it appears that we should always use getSession(true). However, you should be careful in that a denial-of-service attack can be allowed by always creating new sessions on demand. An unscrupulous user could discover your site was creating sessions and flood it with new session requests. By using getSession(false) and then redirecting to a login page when a session is not detected, you can protect against such an attack.

In addition, there are many other interesting methods on HttpSession objects, such as isNew(), getAttribute(), setAttribute(), etc. The interested reader is pointed to the servlet specification for an exhaustive review.

Now that we understand the lifecycle of a session, how do we go about obtaining a session and using it to our advantage? The HttpServletRequest interface provides two methods for working with sessions:

public HttpSession getSession() always returns either a new session or an existing session.

getSession() returns an existing session if a valid session ID was somehow provided (perhaps via a cookie). It returns a new session in several cases: the client's initial session (no session ID provided), a timed-out session (session ID provided), an invalid session (session ID provided), or an explictly invalidated session (session ID provided).
public HttpSession getSession(boolean) may return a new session, an existing session, or null.

getSession(true) returns an existing session if possible. Otherwise it creates a new session. getSession(false) returns an existing session if possible and otherwise returns null.

We have still only solved half of the problem at hand. We'd like to be able to skip over the "session new" state and move to the "session in use" state automatically. We can achieve this by redirecting the browser to the handling servlet automatically. Listing 3 combines servlet session logic with the ability to redirect clients with valid sessions to the handling servlet.

Listing 3: RedirectServlet.java

01: package multiplesubmits;
02:
03: import java.io.*;
04: import java.util.Date;
05: import javax.servlet.*;
06: import javax.servlet.http.*;
07:
08: public class RedirectServlet extends HttpServlet{
09: 	public void doGet (HttpServletRequest req, HttpServletResponse res)
10: 		throws ServletException, IOException {
11: 		HttpSession session = req.getSession(false);
12: 		System.out.println("");
13: 		System.out.println("-------------------------------------");
14: 		System.out.println("SessionServlet::doGet");
15: 		System.out.println("Session requested ID in Request:" +
16: 		req.getRequestedSessionId());
17: 		if ( null == req.getRequestedSessionId() ) {
18: 			System.out.println("No session ID, first call,
    				creating new session and forwarding");
19: 			session = req.getSession(true);
20: 			System.out.println("Generated session ID  in Request: " +
21: 				session.getId());
22: 			String encodedURL = res.encodeURL("/RedirectServlet");
23: 			System.out.println("res.encodeURL(\"/RedirectServlet\");="
   					+encodedURL);
24: 			res.sendRedirect(encodedURL);
25: //

26: 			// RequestDispatcher rd = getServletContext().getRequestDispatcher(encodedURL);
27: 			// rd.forward(req,res);

28: //
29: 			return;
30: 		}
31: 		else {
32: 			System.out.println("Session id = " +
					req.getRequestedSessionId() );
33:				 System.out.println("No redirect required");
34: 		}
35:
36: 		HandleRequest(req,res);
37: 		System.out.println("SessionServlet::doGet returning");
38: 		System.out.println("------------------------------------");
39: 		return;
40: 	}
41:
42: 	void HandleRequest(HttpServletRequest req, HttpServletResponse res)
43: 	throws IOException {
44: 		System.out.println("SessionServlet::HandleRequest  called");
45: 		res.setContentType("text/html");
46: 		PrintWriter out = res.getWriter();
47: 		Date date = new Date();
48: 		out.println("<html>");
49: 		out.println("<head><title>Ticket Confirmation</title></head>");
50: 		out.println("<body>");
51: 		out.println("<h1>The Current Date And Time  Is:</h1><br>");
52: 		out.println("<h3>" + date.toString()  + "</h3>");
53: 		out.println("</body>");
54: 		out.println("</html>");
55: 		System.out.println("SessionServlet::HandleRequest returning");
56: 		return;
57: 	}
58: }

Just how does this solve our problem? Examining the code closely shows that on line 11 we try to obtain a session handle. On line 17 we identify that an active session exists by checking the session ID for null, or by checking for a valid session ID. Either method suffices. Lines 18-29 are executed if no session exists. We handle the multiple submit problem by first creating a session as shown on line 19, using URL encoding to add the new session ID as shown on line 22, and then redirecting our servlet to the newly encoded URL, as shown on line 24.

NOTE: forward Vs. sendRedirect

Lines 26 & 27, while commented out, are shown as an example of something not to do. On first glance, forward seems to be a better solution to our problem because it does not cause a round trip to the browser and back. However, forward comes at a price; the new session ID is not attached to the URL. Using forward would cause the servlet to be called over and over in a loop, ultimately killing the application server.

Readers unfamiliar with URL rewriting are directed to lines 15 and 23. An HttpServlet object has the ability to rewrite a URL. This process inserts a session ID into a URL. The underlying application server can then use the encoded URL to provide an existing session automatically to a servlet or JSP. Depending on the application server, you may need to enable URL rewriting for the above example to work!

Conclusion

In this article, we discussed several solutions to the multiple submit problem. Each solution has its positive and negative aspects. When solving problems, the various pros and cons of a solution must be clearly understood to assess the value of each tradeoff. Our final example had the benefit of solving the problem at hand at the cost of an extra client round trip. The JavaScript solution was the most elegant, but required client support to work. As with any problem, there are often a world of solutions, each one with its own trade-offs. By understanding the trade-offs of a given solution, we can make the most informed choice for a given problem.

Al Saganich is BEA Systems' senior developer and engineer for enterprise Java technologies, focused on Java integration and application with XML and Web services.

Return to ONJava.com.