Re: Stopping Double Submits via mutex
Let's also not exagerate here. Rewrite the complete system? Come on. It's a request interceptor that manages a webflow stack for each user. If anything, you're just adding a module with some minor GUI mods. Dr. Z apparently thinks that an application, once released, may not have subsequent release despite unexpected success of the application or the company in general. Push it off until it's needed. This obviously has more to do with philosophy than it does with the original question. On 6/21/06, Andreas Winkler <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 But on the other hand if you had a client who wanted a cluster you could make one, but not if because of the underlying classes you had to rewrite the complete system. And as I experienced it, cluster/redundancy seem to get more and more important and there is no way around it. In an environment where every company has to be online 24/7 failure safety becomes a very crucial subject, especially for small companies. Monkeyden wrote: > I'd be surprised if that data was out there but logic tells me that > there > are far more small-med applications than there are med-large. Of > course the > underlying point is that every feature should be considered with it's > probability of being used. We do this all the time when we > determine scope > for each release. The most needed features typically get priority > on the > release schedule. > > The CTO of a company I worked for in 2001 wanted a web service based > platform (what came to be known as SOA) to use for our hosted > clients. We > defined the schemas, service locators, developed the web services, > EJBs and > a decoupled web layer, created a template engine for the request > documents > and many more utilities to simplify the XML work, etc, etc, etc. > When it > was done we had 20+ clients running on the platform and not a single > one was > on a cluster. An early full-feature release of an application > won't, and > shouldn't, attempt to solve all the problems which are out of > context for > the release. Make it a consideration? Absolutely, but the "what > if" part > of pragmatism is often taken too far, and to great and unecessary > expense. > > On 6/21/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> >> Monkeyden, I'd be careful with that assumption... clustering is pretty >> common in mid to large organizations based on my experience... I think >> any design that doesn't take it into consideration is a bad design. >> Even if your in a 5-person shop now running on a single server, do you >> want to deal with it 2 years down the road when all of a sudden your a >> big success, but your app won't scale to a clustered environment? >> >> I'd personally like to see some statistics that support either of our >> beliefs :) I'm not aware of any, although I'd bet they're out there. >> Even if it was true that the overwhelming majority of applications run >> on a single JVM, I would still contend it's a bad design practice >> to not >> plan for clustering... or at least, to do something that you know >> would >> be problematic in a cluster (and the difficulties can be very >> subtle, I >> can say that for sure from experience). >> >> Frank >> >> Monkeyden wrote: >> > I'm as forward-thinking as the next guy but let's not lose sight >> of the >> > fact >> > that, despite how pragmatic we engineers like to be, many more >> than half >> of >> > the applications developed and deployed are done so on a single >> JVM. An >> > overwhelming majority of those applications originally deployed on a >> single >> > JVM will never see a cluster. If you're grounded in reality, and >> not >> "what >> > if...", there is no sense in wasting time and resources developing >> > something >> > that will never be used. >> > >> > >> > On 6/21/06, Madhav Bhargava <[EMAIL PROTECTED]> wrote: >> >> >> >> For a single JVM this is a nice way to handle multipel submits. But >> >> then a >> >> solution should never be limited to one JVM and if it has >> problems when >> >> multiple JVM;s come into the picture then it should re-thought >> upon. I >> >> would >> >> rather not go for such a solution even though it is a good >> solution for >> a >> >> single JVM. >> >> >> >> On 6/21/06, Paul Benedict <[EMAIL PROTECTED]> wrote: >> >> > >> >> > Yes - of course it would. The solution is only for one JVM. >> You will >> >> need >> >> > another approach for a clustered environment. >> >> > >> >> > Madhav Bhargava <[EMAIL PROTECTED]> wrote: 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 >> >> > wrote: >> >> > > >> >> > > I've read many different te
Re: Stopping Double Submits via mutex
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 But on the other hand if you had a client who wanted a cluster you could make one, but not if because of the underlying classes you had to rewrite the complete system. And as I experienced it, cluster/redundancy seem to get more and more important and there is no way around it. In an environment where every company has to be online 24/7 failure safety becomes a very crucial subject, especially for small companies. Monkeyden wrote: > I'd be surprised if that data was out there but logic tells me that > there > are far more small-med applications than there are med-large. Of > course the > underlying point is that every feature should be considered with it's > probability of being used. We do this all the time when we > determine scope > for each release. The most needed features typically get priority > on the > release schedule. > > The CTO of a company I worked for in 2001 wanted a web service based > platform (what came to be known as SOA) to use for our hosted > clients. We > defined the schemas, service locators, developed the web services, > EJBs and > a decoupled web layer, created a template engine for the request > documents > and many more utilities to simplify the XML work, etc, etc, etc. > When it > was done we had 20+ clients running on the platform and not a single > one was > on a cluster. An early full-feature release of an application > won't, and > shouldn't, attempt to solve all the problems which are out of > context for > the release. Make it a consideration? Absolutely, but the "what > if" part > of pragmatism is often taken too far, and to great and unecessary > expense. > > On 6/21/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> >> Monkeyden, I'd be careful with that assumption... clustering is pretty >> common in mid to large organizations based on my experience... I think >> any design that doesn't take it into consideration is a bad design. >> Even if your in a 5-person shop now running on a single server, do you >> want to deal with it 2 years down the road when all of a sudden your a >> big success, but your app won't scale to a clustered environment? >> >> I'd personally like to see some statistics that support either of our >> beliefs :) I'm not aware of any, although I'd bet they're out there. >> Even if it was true that the overwhelming majority of applications run >> on a single JVM, I would still contend it's a bad design practice >> to not >> plan for clustering... or at least, to do something that you know >> would >> be problematic in a cluster (and the difficulties can be very >> subtle, I >> can say that for sure from experience). >> >> Frank >> >> Monkeyden wrote: >> > I'm as forward-thinking as the next guy but let's not lose sight >> of the >> > fact >> > that, despite how pragmatic we engineers like to be, many more >> than half >> of >> > the applications developed and deployed are done so on a single >> JVM. An >> > overwhelming majority of those applications originally deployed on a >> single >> > JVM will never see a cluster. If you're grounded in reality, and >> not >> "what >> > if...", there is no sense in wasting time and resources developing >> > something >> > that will never be used. >> > >> > >> > On 6/21/06, Madhav Bhargava <[EMAIL PROTECTED]> wrote: >> >> >> >> For a single JVM this is a nice way to handle multipel submits. But >> >> then a >> >> solution should never be limited to one JVM and if it has >> problems when >> >> multiple JVM;s come into the picture then it should re-thought >> upon. I >> >> would >> >> rather not go for such a solution even though it is a good >> solution for >> a >> >> single JVM. >> >> >> >> On 6/21/06, Paul Benedict <[EMAIL PROTECTED]> wrote: >> >> > >> >> > Yes - of course it would. The solution is only for one JVM. >> You will >> >> need >> >> > another approach for a clustered environment. >> >> > >> >> > Madhav Bhargava <[EMAIL PROTECTED]> wrote: 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 >> >> > 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 >>
Re: Stopping Double Submits via mutex
I'd be surprised if that data was out there but logic tells me that there are far more small-med applications than there are med-large. Of course the underlying point is that every feature should be considered with it's probability of being used. We do this all the time when we determine scope for each release. The most needed features typically get priority on the release schedule. The CTO of a company I worked for in 2001 wanted a web service based platform (what came to be known as SOA) to use for our hosted clients. We defined the schemas, service locators, developed the web services, EJBs and a decoupled web layer, created a template engine for the request documents and many more utilities to simplify the XML work, etc, etc, etc. When it was done we had 20+ clients running on the platform and not a single one was on a cluster. An early full-feature release of an application won't, and shouldn't, attempt to solve all the problems which are out of context for the release. Make it a consideration? Absolutely, but the "what if" part of pragmatism is often taken too far, and to great and unecessary expense. On 6/21/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: Monkeyden, I'd be careful with that assumption... clustering is pretty common in mid to large organizations based on my experience... I think any design that doesn't take it into consideration is a bad design. Even if your in a 5-person shop now running on a single server, do you want to deal with it 2 years down the road when all of a sudden your a big success, but your app won't scale to a clustered environment? I'd personally like to see some statistics that support either of our beliefs :) I'm not aware of any, although I'd bet they're out there. Even if it was true that the overwhelming majority of applications run on a single JVM, I would still contend it's a bad design practice to not plan for clustering... or at least, to do something that you know would be problematic in a cluster (and the difficulties can be very subtle, I can say that for sure from experience). Frank Monkeyden wrote: > I'm as forward-thinking as the next guy but let's not lose sight of the > fact > that, despite how pragmatic we engineers like to be, many more than half of > the applications developed and deployed are done so on a single JVM. An > overwhelming majority of those applications originally deployed on a single > JVM will never see a cluster. If you're grounded in reality, and not "what > if...", there is no sense in wasting time and resources developing > something > that will never be used. > > > On 6/21/06, Madhav Bhargava <[EMAIL PROTECTED]> wrote: >> >> For a single JVM this is a nice way to handle multipel submits. But >> then a >> solution should never be limited to one JVM and if it has problems when >> multiple JVM;s come into the picture then it should re-thought upon. I >> would >> rather not go for such a solution even though it is a good solution for a >> single JVM. >> >> On 6/21/06, Paul Benedict <[EMAIL PROTECTED]> wrote: >> > >> > Yes - of course it would. The solution is only for one JVM. You will >> need >> > another approach for a clustered environment. >> > >> > Madhav Bhargava <[EMAIL PROTECTED]> wrote: 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 >> > 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 progress
Re: Stopping Double Submits via mutex
Monkeyden, I'd be careful with that assumption... clustering is pretty common in mid to large organizations based on my experience... I think any design that doesn't take it into consideration is a bad design. Even if your in a 5-person shop now running on a single server, do you want to deal with it 2 years down the road when all of a sudden your a big success, but your app won't scale to a clustered environment? I'd personally like to see some statistics that support either of our beliefs :) I'm not aware of any, although I'd bet they're out there. Even if it was true that the overwhelming majority of applications run on a single JVM, I would still contend it's a bad design practice to not plan for clustering... or at least, to do something that you know would be problematic in a cluster (and the difficulties can be very subtle, I can say that for sure from experience). Frank Monkeyden wrote: I'm as forward-thinking as the next guy but let's not lose sight of the fact that, despite how pragmatic we engineers like to be, many more than half of the applications developed and deployed are done so on a single JVM. An overwhelming majority of those applications originally deployed on a single JVM will never see a cluster. If you're grounded in reality, and not "what if...", there is no sense in wasting time and resources developing something that will never be used. On 6/21/06, Madhav Bhargava <[EMAIL PROTECTED]> wrote: For a single JVM this is a nice way to handle multipel submits. But then a solution should never be limited to one JVM and if it has problems when multiple JVM;s come into the picture then it should re-thought upon. I would rather not go for such a solution even though it is a good solution for a single JVM. On 6/21/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > > Yes - of course it would. The solution is only for one JVM. You will need > another approach for a clustered environment. > > Madhav Bhargava <[EMAIL PROTECTED]> wrote: 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 > 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 > > > > > - > Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great > rates starting at 1¢/min. > -- 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 -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stopping Double Submits via mutex
I'm as forward-thinking as the next guy but let's not lose sight of the fact that, despite how pragmatic we engineers like to be, many more than half of the applications developed and deployed are done so on a single JVM. An overwhelming majority of those applications originally deployed on a single JVM will never see a cluster. If you're grounded in reality, and not "what if...", there is no sense in wasting time and resources developing something that will never be used. On 6/21/06, Madhav Bhargava <[EMAIL PROTECTED]> wrote: For a single JVM this is a nice way to handle multipel submits. But then a solution should never be limited to one JVM and if it has problems when multiple JVM;s come into the picture then it should re-thought upon. I would rather not go for such a solution even though it is a good solution for a single JVM. On 6/21/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > > Yes - of course it would. The solution is only for one JVM. You will need > another approach for a clustered environment. > > Madhav Bhargava <[EMAIL PROTECTED]> wrote: 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 > 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 > > > > > - > Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great > rates starting at 1¢/min. > -- 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
Re: Stopping Double Submits via mutex
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]
Re: Stopping Double Submits via mutex
For a single JVM this is a nice way to handle multipel submits. But then a solution should never be limited to one JVM and if it has problems when multiple JVM;s come into the picture then it should re-thought upon. I would rather not go for such a solution even though it is a good solution for a single JVM. On 6/21/06, Paul Benedict <[EMAIL PROTECTED]> wrote: Yes - of course it would. The solution is only for one JVM. You will need another approach for a clustered environment. Madhav Bhargava <[EMAIL PROTECTED]> wrote: 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 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 - Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. -- 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
Re: Stopping Double Submits via mutex
Yes - of course it would. The solution is only for one JVM. You will need another approach for a clustered environment. Madhav Bhargava <[EMAIL PROTECTED]> wrote: 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 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 - Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min.
Re: Stopping Double Submits via mutex
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 <[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 - 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
Stopping Double Submits via mutex
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.
