I had thought about that. I like this idea, but just having mutex is not enough. Consider following scenario:
* A user submits a request, say this is a checkout process * Server locks the session * The user is impatient and submits another request, but it waits on the mutex * First request finishes and sends respond back * Second request is free to go, it checks shopping cart status, it is already processed, so it returns Now, what will the user see? Apparently, the first response will be overwritten with the second response. Great if they contain the same information, but what if the second one is just "ok, data processed" or they are different in some other way? I guess, that incoming threads should wait on resource, then when server finishes processing, it should kill all request threads but the *last* one, and return the response with it. So, instead of a simple mutex there should be a thread management module that switches response initially bound to the first thread onto the last thread and kills other threads. I have never tried it, maybe this is not a right idea ;-) On 6/20/06, Paul Benedict <[EMAIL PROTECTED]> 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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
