Keep Track Of Ajax Request

Ne开发者_如何学编程wbie here..

I just want to ask how can I accomplish my homework in school. I basically have this need.

I want to send an ajax request every 10 seconds but I dont want to initiate another request if my previous request has not returned yet.

I am thinking that the connection to DB might be that bad sometimes so I would like to wait for my previous request to be finished (success/failed/error) before I fire up another.

I check on javascript and and found the setinterval method. But how can I line up my ajax request so that the server doesnt get fired up by many ajax request?

I am studying jquery right now and is using JSON.

One method would be to set a variable to false when you send out a request. When you get it back set it back to true. When you go to send out a new ajax request make sure the value is true. If not add it to a queue of some sort so that it will be called when the request is finished. However if every request takes longer then ten seconds your queue will get pretty backed up. So you may not want a queue. So instead when you go to send out the ajax request if the variable is false you just wait another ten seconds.

I'll even help more:

    var isWatingForResponse = false;

    $.ajax({
        url: 'wherever'
        ,dataType: 'json'
        ,beforeSend: function() {
            if(isWatingForResponse) {
                return false;
            }
            isWatingForResponse = true;
        }
        ,complete: function() {
            isWatingForResponse = false;
        }
        ,success: function (data) {
            //process data
        }
    });

Or follow @qw3n answer. This should work with jQuery 1.4.2

As I see the OP question:

How to set up fault-tolerance on the client-side because of Db-server issues, using jQuery Ajax?

This IMHO, is a really good question. If I may, I would like to map out the pipe:

web-client->network->web-server->network->Db-server

Db-server->network->web-server->network->web-client

Your solution to this problem of handling issues with the db-server in the client is workable, but really does not address the actual problem. It could really cripple you for future extension of your client.

You should really be handling this issue as close to the problem as possible. In the web-server.