I've just come off implementing something very much like what Wade has
recommended, and it works a treat.
Note the use of a finally block to release the session lock, which is cool.
Basically, the first request sets a flag stored in the session object so
that no other (subsequent) request will be processed for that session
object.
The problem is that the response from the first request will never be
received by the client, if the client manages to send another request before
the first one has responded.
If the client sends another request whilst the first is still processing,
the controller servlet redirects the request to come back to the server (and
make a fresh request) in the expectation that the first request will have
finished by the time the second request has re-bounded.
The server keeps a count of how many 'rebounds' are made, so that if the
first request is taking a long time to process, the 3rd rebound is passed to
a 'progress bar' JSP that is programmed to refresh itself at increasingly
slower rates. (I use custom tags to programmatically set the refresh rate.)
It is theoretically possible for the user to be left in limbo if something
happens to permanently block the processing of the first request - but that
is an unlikely event, so the risk is worthwhile.
The cool bit is that once the fist request has finished processing it sets a
'state' attribute (or set of attributes) in the session, so that any
subsequent request (a rebound or a progress-bar JSP seeking to refresh
itself) will get a response that is identical to what the first request
would have generated.
That's kind of like a restaurant where the customer can never change their
order. If they ask for a salad, that is it. No matter how long it takes to
cook, and however many times they ask to change their order to chicken, they
get a salad at the end!
This stuff can really do your head in when you first start thinking about
it, but after while it gets easier.
Bottom line: session is you best friend. Use it.
Good luck!
Harry Mantheakis
London, UK
> Replying on top of Yoav's because I don't have the other message.
>
> If it is a large enough operation your could do something like this:
>
> //check if running
> String methodName = "com.mypackage.MyClass.myMethod";
> //pull value from session test and add if needed.
> Boolean isRunning = (Boolean)session.getAttribute(methodName);
> if( isRunning != null && isRunning.booleanValue() )
> {
> //hand off to other method that tells them to please wait.
> }
> else
> {
> //first let app know user is doing task.
> session.setAttribute(methodName, new Boolean(true));
>
> //perform that large task
> try
> {
> //do work that might jump out here...
> }
> catch(Throwable e)
> {
>
> }
> finally
> {
> //ok, it's done...remove from session.
> session.removeAttribute(methodName);
> }
> }//end else
>
> Now the large task can't eat up your cpu more than you let it because it
> only runs once per user at a time. Sleeping the thread a little after
> so many iterations in loops also will help your entire server and
> application. After maybe every 1000 iterations sleep for a couple of
> millis. Play with that sometimes it helps sometimes not. It spreads out
> the load over time a bit and allows the computer to service more users,
> it just takes longer...
>
> Hope that helps you some.
>
> Wade
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
