struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Madhav Bhargava" <unmarsh...@gmail.com>
Subject Re: Stopping Double Submits via mutex
Date Wed, 21 Jun 2006 08:40:21 GMT
Consider a scenario of a clustered environment where there are multiple
servers handling requests from an application. On each of these servers
session object will be replicated. This means that the same request can go
more than once.

Shouldn't this solution fail then?

~madhav

On 6/21/06, Paul Benedict <paul4christ79@yahoo.com> wrote:
>
> I've read many different techniques to stopping double submits, but one
> technique unfamiliar to me was described inside the Spring Framework.
>
>
> http://www.springframework.org/docs/api/org/springframework/web/util/HttpSessionMutexListener.html
>
> It did not occur to me to lock the session to make sure that, within a
> user's dialog with the server, only one request from a session makes it
> through. Now read that carefully: not one user, but one request from one
> user. So 1000 different threads can be running, but locking the session will
> ensure each is from a unique session.
>
> However, this class exists because some application servers do not
> guarantee that the same HttpSession object instance is re-used between
> requests. But the application server does need to guarantee the same object
> instance with the session... So Spring provides this class (nothing but a
> marker interface) if you want to head down this road.
>
> What do people think of locking the session via a session object? I like
> it, but I haven't implemented it -- but I want to use it if the feedback is
> good. I have a few places in my application in which I want to make sure the
> user progresses through my cattle chute in an orderly fashion.
>
> Paul
>
>
> ---------------------------------
> Do you Yahoo!?
> Everyone is raving about the  all-new Yahoo! Mail Beta.
>



-- 
When I tell the truth, it is not for the sake of convincing those who do not
know it, but for the sake of defending those that do

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message