As far as I know, Ajax using XHR can handle only one response per one request. It seems to be limitation of web applications that uses Ajax. For example, web page displays a table by querying to a server, but it takes several minutes for server to retrieve all data. So, I want to make server to responses currently retrieved data every 10 second and client handles every response. Is it possible or is there any workaround?
Originally posted by Ben Souther: This is typically done by having the client poll the server every n seconds to see if the job is done.
Thanks for your reply. I used client polling, but not satisfied with it. My dissatisfaction may comes from wrong design of server side. I can design 2 types of server-side as below
(a) In server side, jsp retrieves data and writes currently retrieved records to a output file which is the target of client's query. : It is simple, but on each polling, reponse text is not delta but accumulative records.
(b) In server side, jsp is the target of client. Query string to the jsp should include client ID and query sequence number. If sequence num is 0, jsp starts retrieving data and writes them to a output file(Each ID has own output file). If it is over 0, jsp reads some records (stored in output file) corresponding to ID/sequence number and returns the records.
I am using design similar to (a). Is (b) reasonable and the way typically used? Could you share nice ideas on this issue? [ January 17, 2008: Message edited by: Daesung Park ]
It was kept as simple as possible so it refreshes the whole page instead of using AJAX but the same principals apply. It also uses a session scoped object to store the state of the long running job. In the real world, I store the state in a database table so the user doesn't need to keep a session alive in order to keep in touch with the job.
In a nutshell, I kick off the the job in a new thread and immediately return a status pages that refreshes every n seconds. With each refresh, it checks for a 'Done' status. If not done, then I return the refreshing status page. If done then I return the resulting page, report, file, whatever...
It would be very easy to adapt this model to use AJAX and a database. Another nice touch would be to have the app email the user once the job is complete so she can do other things while waiting for the job to finish.
Also, in the real world, (and I think this might answer your 'B' scenerio), the refreshing page has a list of all jobs -- finished and unfinished -- by this user so she has the option of viewing previous reports generated with this component.