Hi Nick!
It occurs to me as if you need to make your system a little bit more
complex. If requests can take such a long time to process, there
are many factors that might require certain additional effort
to ensure that your system is not going to suffer a breakdown due to
its load....
I would suggest that you split off the processing (e.g I guess
information gathering and layouting) from the servlet.
Now get the running servlet thread into a blocked state, which means
don`t let it hog your system.
This can be easily achieved by using a pipe :) I have tried that
already and I know it works perfectly.
Now:
1. store a flag in the session that marks it having a request pending.
2. make the processor performing its work on the (Get-1) request. Give this
method the servlets pipe end as parameter.
3. read from the pipe end (this will put your servlets thread in a blocked
state, thus not hog the system)
4. Whenever there is something coming over the pipe you can
collect the result and start to stream output to the Get-1 response.
How you use the pipe is up to your imagination, you can either choose
to directly send the processors output to it, or you can just send a byte
to get the servlet out of its blocked state, or you can even make up a
complete "protocol".
5. I am not sure, but I guess you can somehow find out if the line to
the user is still active or if the user broke it.
I think output performed to a broken link should definately
give you an exception.
Now if the user hits stop, and issues another request,
you
1. know its already processing a request, but broke off
2. can do different things depending on your sites policy:
- hook him up the old request
- remind the user processing costs money and resources and
let him/her decide if he/she wants to process his new request
or finally see the results of the old request.
- whatever you can think off.
This requires only that the processor holds the results for a certain
time. You can use a watchdog thread to perfom cleanup, or you can write
the result as page to a temporary file (using a script cleaning up this
dir every now and then) etc. etc.
You see you can easily circumvent the issues you mentioned,
and maybe come up with more interactive and elegant solutions :)
If you took a decision about what you want to do, donīt hesitate
to ask for some example code. I think I can come up with some.
Hope that helped a little
Regards
Dieter Wimberger
>Situation:
>
>A user issues a get (Get-1) which takes 30 seconds to complete.
>2 seconds later, user presses STOP and issues another get (Get-2)
>which only takes 10 seconds to complete.
>
>Suppose both Get-1 and Get-2 USE information in the session
>and PUT information in the session.
>
>I believe JServ handles this with two threads and I believe
>the two threads will be colliding on the session variables.
>
>Possible Solution:
> 1) create a deep-copy of the session
> 2) each thread use/update their own copy
> 3) when processing of the GET request is complete,
> each thread updates the session with their copy.
> EXCEPT, do not update if the timestamp in the session
> is newer than the timestamp in the copy.
> AND, make sure that step 3 is done in a threadsafe manner.
>
>This puts quite a burden on the servlet developer to not use the session
>and only use the copy -- and, it seems like a rather awkward solution.
>
>Anybody know of a better solution?
>
>-Nick Ide (National Library of Medicine)
>
>
>------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Problems?: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
