Topic
  • 3 replies
  • Latest Post - ‏2012-12-11T17:00:28Z by kevintap
HSSH_Sandip_Kulkarni
13 Posts

Pinned topic Cancel a Ajax request

‏2012-11-20T14:17:32Z |
Whenever an html action event is triggered from the browser and if smart refresh or similar is used, we see a progress indicator spinner running. In some cases where the response time is longer, I want to add the flexibility for the users to be able cancel the request and proceed.

How cac this be achieved.
Updated on 2012-12-11T17:00:28Z at 2012-12-11T17:00:28Z by kevintap
  • DGawron
    DGawron
    50 Posts

    Re: Cancel a Ajax request

    ‏2012-11-28T15:57:14Z  
    Cancelling a smart refresh request (or any HTTP request for that matter) is much more complicated than it first appears. My recommendation is to make the target action / page response fast enough so that users don't need a "cancel" option.

    The usual cause of slow refresh behavior is slow access to some back-end or trying to perform too many back-end operations per request. Do everything you possibly can to make back-end access fast. This involves using paged access to results, caching where appropriate, reducing the amount of data accessed and returned for each page, refreshing smaller portions of a page, off-loading back-end access to an ESB, etc.

    While cancelling the spinner is technically possible (but undocumented from what I can tell), that's not the hard problem. The hard problem is cancelling the running HTTP request and rolling back changes to the back-end(s) and the model state.
  • HSSH_Sandip_Kulkarni
    13 Posts

    Re: Cancel a Ajax request

    ‏2012-12-10T11:58:07Z  
    • DGawron
    • ‏2012-11-28T15:57:14Z
    Cancelling a smart refresh request (or any HTTP request for that matter) is much more complicated than it first appears. My recommendation is to make the target action / page response fast enough so that users don't need a "cancel" option.

    The usual cause of slow refresh behavior is slow access to some back-end or trying to perform too many back-end operations per request. Do everything you possibly can to make back-end access fast. This involves using paged access to results, caching where appropriate, reducing the amount of data accessed and returned for each page, refreshing smaller portions of a page, off-loading back-end access to an ESB, etc.

    While cancelling the spinner is technically possible (but undocumented from what I can tell), that's not the hard problem. The hard problem is cancelling the running HTTP request and rolling back changes to the back-end(s) and the model state.
    While I understand that optimizing the backend calls should be be looked into, but my backend call involves calling a webservice which takes 7-10 seconds to respond as it fetches data from a large old legacy application, where optimization is out of my scope and hence I want to provide users with options to cancel the request.

    What would be the suggestions to
    • cancel the spinner
    • cancel the http Ajax request itself
  • kevintap
    kevintap
    9 Posts

    Re: Cancel a Ajax request

    ‏2012-12-11T17:00:28Z  
    While I understand that optimizing the backend calls should be be looked into, but my backend call involves calling a webservice which takes 7-10 seconds to respond as it fetches data from a large old legacy application, where optimization is out of my scope and hence I want to provide users with options to cancel the request.

    What would be the suggestions to
    • cancel the spinner
    • cancel the http Ajax request itself
    I would advise caution here. As Dave pointed out, the hard part is cancelling the running HTTP request on the server. WEF implements a semaphore (per model, per user) which is owned by the current thread executing the HTTP request on the app server. (The semaphore is designed such that only one thread executing on the app server can make changes to the application's internal state.) If you abandon this request, the app server will still continue to execute the request thread and the request thread will continue to own the semaphore until it completes the request. Issuing a second request from the browser will cause the second request to block and wait until the first, abandoned request is complete.

    The postings on this site are my own and do not necessarily represent the positions, strategies, or opinions of IBM.