If security isn't an issue store it in the "job id" in the URL
http://my.company.com/servlet/getlongactionResult?jobid=1234
Even if the "session" times out, the user can check on the job
-----Original Message-----
From: Joe Peer [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 07, 2001 9:23 AM
To: [EMAIL PROTECTED]
Subject: Re: Using Struts to achieve asynchronous comms
hi,
maybe my approch is ridicolous but it would be very simple:
szenario:
1. your client request servlet url.
(your servlet stores the session id of your user (in any way) to remember
him/her)
2. your servlets starts the process doing the heavy work (i suppose ;=)
3. your servlet sends *immediate* response, containing a html site with a
meta refresh tag or some other code forcing the users browser to reload the
site (== contact the servlet url), ie. every minute or so
4. every time the servlet gets contacted it checks if the working process
is finished for the user. if not ready it sends the same html site again
5. finally if the user contacts the servlet again and if the result is
available you redirect or forward him/her to the result page
this is how i would do it probable
joe
At 18:08 07.02.01, you wrote:
>Hello all. I've been wrestling with an asynchronous comms problem (for
>almost a week) and am wondering if implementing struts can help.
>I'm developing a web application that'll send a message to a server,
>then wait for a response and display that response to a web browser (the
>client). The problem is, the server requires an indeterminate
>amount of time (from several seconds up to minutes, perhaps even hours
>in production) so the servlet must 'wait' somehow until a response is
>ready. Implementing blocking calls at the servlet level doean't seem
>the way to go and I don't think a producer/consumer pattern will help
>either.
>
>Still searching the archives (my connection is unreliable today for some
>reason) so my apologies if this has been dealt with already. Please
>point me to the right resources if possible. Thanks in advance for any
>and all replies.
>
>Greg
