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
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
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
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
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
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
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
-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
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
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
10 matches
Mail list logo
