After thinking about this a little more, I realized that we may have confused two separate issues. I am not worried about processing the same request more than once. Instead, I'm trying to prevent *concurrent* processing of duplicate requests. Concurrent processing of duplicate requests will lead to optimistic locking exceptions which are undesirable in certain circumstances. I only know of two ways to do prevent it:
1.) synchronize on the session (or an object in the session) during the event handling 2.) obtain pessimistic database locks at the beginning of the request and only commit the transaction at the end of the event handling So I guess I'm asking whether anyone else sees another option. Failing that, which of these two method makes the most sense? On May 25, 2009, at 2:41 PM, Michael Day wrote: > Hi Oscar, > > One of my use cases is order checkout. The last thing I want to do is > show an error page to the user, even if they are dumb enough to submit > twice. > > How do you recognize the second submission? Are you using a hidden > token in the form? Just checking whether the same action is called > twice in a certain period of time isn't robust enough. Sometimes > ActionBean execution could take longer than a few seconds. > > I'm already doing exactly as you said (skip processing and redirect to > result page immediately) in my submit handler by looking at the status > of the order. If the status is Submitted, I'm just showing the result > page. But for this to work properly, I have to obtain a pessimistic > lock on the order at the beginning of the request. > > I'm curious how amazon handles this. I tried double-submitting some > forms on their site, but it seems like they either somehow abort all > but the last request or have a filter that caches the first submission > and shows it on subsequent requests. I'm not sure how they would have > a filter, though, because there is no hidden token in the form. > > On May 25, 2009, at 2:15 PM, Oscar Westra van Holthe - Kind wrote: > >> On 25-05-2009 at 19:09, Richard Hauswald wrote: >>> You could track the calls to site with an interceptor, storing the >>> last requested page and access time in the session. If the same >>> action >>> bean is called twice within 1 second, return a ForwardResolution >>> to a >>> page explaing that the user should not double klick. I would not >>> synchronize access to the session before I have fully understood the >>> the issue und can think of all possible problems... Multithreading >>> is >>> a very complex topic and relating to web apps most people try to >>> avoid >>> synchronized access to a resource. Personally I would discard users >>> who disabled java script and solve the problem using js. >> >> I second that. Your best bet is to recognize a second call. You may >> then >> abort the request and explain the situation (as described by >> Richard). >> >> Personally, I prefer to extend the post-redirect-get pattern by >> skipping the >> action and redirecting to the result page immediately. You can then >> also >> use the flash scope to display a message, or even add a (temporary) >> meta tag >> to reload the page after a few seconds (the reloaded page doesn't >> contain >> that meta tag). >> >> >> Oscar >> >> -- >> ,-_ Oscar Westra van holthe - Kind http://www.xs4all.nl/~kindop/ >> /() ) >> (__ ( Inequality is the inevitable consequence of liberty. >> =/ () -- Salvador De Madariaga - "Anarchy or Hierarchy" (1937) ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com _______________________________________________ Stripes-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-users
