Dieter,
Thanks for the response. It isn't really a matter of requests
taking a "long time" to process. A "long time" is in the eye of the
beholder and depends on server load etc. Even a 5 second request
can be overtaken by a stop and a 1 second request. The bottom line
is that session information is always vulnerable to stop/resubmit problems.
-Nick
> 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]
>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
