Comments on: AJAX and Session “Race Conditions”

By: ringobob

ringobob — Fri, 03 Mar 2006 01:59:58 +0000

for example (sorry for the second post), keep a stack of requests, ordered by the submitted timestamp, and just compare the current request submit time to the top of the stack, if it’s newer execute as normal, if it’s older fit it in the stack and act appropriately (e.g. re-execute from current request to the end, don’t execute at all, warn user, etc.).

All of this assumes that you won’t be sending requests quicker than 1/millisecond, at least not with Date’s getTime(). I’d guess that’s a pretty reasonable assumption in most cases.

By: ringobob

ringobob — Fri, 03 Mar 2006 01:42:15 +0000

Well, my AJAX is kind of ready made to handle that… I’ve experienced issues with a single instance of IE returning cached results if I access the same URI, without re-accessing the script. So, I just pop a timestamp on the end of each query string in order to differentiate it and force IE to call the script. For the record, the type of app this has given me issues with is the kind of hybrid HTML++ - Client/SOA much like the script.aculo.us shopping cart you linked to in one of the linked articles.

If this is evidence of some greater deficiency in my code, I’d be happy to hear it, I’m not fond of hacks like this (meaningless querystring variables), but that was the only solution I could find in ~15 minutes of Googling.

Regardless, it would be trivial to use this to keep track of call order.

By: elmer

elmer — Wed, 01 Mar 2006 15:34:00 +0000

would keeping a cookie counter that gets updated before each request help? if the server receives out of order reuests it would buffer and process in-order or time-out as the network stack does? I can see a mild problem when the user branches a web.app in the same browser…

By: Ajaxian » AJAX and Session “Race Conditions”

Ajaxian » AJAX and Session “Race Conditions” — Tue, 28 Feb 2006 13:56:01 +0000

[…] From the SitePoint PHP Blog, there’s a new post from Harry Fuecks that talks about issues concerning race conditions and Ajax. […]

By: wei

wei — Tue, 28 Feb 2006 03:56:50 +0000

If you only care about the latests request/response, you can drop late requests/responses using a counter, 1 keep by the client for responses, 1 keep by the server for requests. If you care about all responses/requests, don’t use AJAX.

By: Luckymonkey » AJAX - pushing JS to places you don’t want to go?

Luckymonkey » AJAX - pushing JS to places you don’t want to go? — Mon, 27 Feb 2006 20:45:11 +0000

[…] (inspired by : SitePoint Blogs » AJAX and Session “Race Conditions”) […]

By: ajking

ajking — Mon, 27 Feb 2006 17:23:32 +0000

Excellent, everybody is in agreement (with Chris Shifflet): if you care about the order in which requests are processed, make sure you do something about it? :-)

By: Ren

Ren — Mon, 27 Feb 2006 17:03:06 +0000

Or server could reply couldn’t perform request 5, because missing requests 3 & 4, and client could re-send them.

By: Ren

Ren — Mon, 27 Feb 2006 16:59:09 +0000

I may have been too hasty with the “ways to prevent that”, some experiements so far havent been too favourable :)

Another off the top of head idea, is take a leaf out of TCP/IPs book, and use ajax request sequence numbers (like packet sequence numbers) if requests come out of order, then server could wait until preceding packets arrive.

By: Joshua Eichorn

Joshua Eichorn — Mon, 27 Feb 2006 16:53:57 +0000

Just a note the solution is not sync calls, it will never be sync calls.

With any sort of decent AJAX library you can easily add support to keep your async calls ordered. Switching to sync will just leave you with a locked UI and higher latency.

HTML_AJAX already has support for keeping AJAX reponses ordered (http://blog.joshuaeichorn.com/archives/2006/02/13/ajax-and-latency/), and if anyone has a reasonable test case, I can add support for ordering requests too the server as well (though its going to take some client side retry code to make it robust.