Shim
Image Gallery User Notes Useful Links Miscellaneous
Shim
Shim

AJAX Threading

This is another set of JavaScript files I wrote to demonstrate the basics of AJAX threading. It seems simpler than the AJAX Queue, but that's only because it leaves more of the "heavy lifting" to you. Threading can be a real bear to implement, and is not for the faint of heart (or messy of code).

The form below allows a fairly intricate demo of threading in action. It can also be used to demonstrate the AJAX Queue. Like my other projects, complete source for a simplified version of this page is available here (Connects to an aggregate SourceForge Project). The main threading support is given in this JavaScript file.

The way this works is you select a multitasking handler (either threaded or queued), and specify a "processing delay" on the server. This is really just a "wait time," and simulates a busy server.

You can have a log displayed below the demo. This gives more information for the threaded implementation than for the queued implementation.

One thing you'll notice about the log is that, in Firefox, the Stage 1 Complex Callback is invoked before the log entry for the initial call. That's because the initial call log entry isn't written until after the program has returned from the initial function call, and the Stage 1 callback happens immediately, but within the excution thread of the initial call. Stage 1 is actually called immediately after the HTTPRequest is made, but the HTTPRequest is logged after returning from the request execution thread. It's just the way the code was written.

Just so you know, I consider this code to be damn near useless, but everyone seems all hopped-up about threading, so I did it. I guess I'll add some thread control stuff like MUTEX and blocking, but it ain't high on my priority list. I use the AJAX Queue Class in all my implementations. It's a LOT easier to use, more predictable and easily meets the needs of all my users. You have to have a particularly twisted mind to design a site where a dozen different connections are going on at once. Users hate that stuff. Just design a good, basic, usable site, and they will love you for it.

QUICK NOTE: I made a mistake (the dangers of cut-and-paste programming), in which I accidentally replaced the thread code with the queue code for a few days. This was not reflected in the .zip file; only the demo on this page. I apologize.

preload preload

Demonstration of Threaded or Queued AJAX

NOTE: There is a 10-Second Timeout Set!


NOTE: I have not completed testing of this! It works well on a number of browsers, but I need to bang on it a bit more with IE6 and 7 (I'm a Mac user, so I tend to write stuff that works well on Macs). If you use this, and you find problems, please let me know. I'll get right on it.

UPDATE: The test implementation (not the actual ajax_thread.js file) is causing issues with IE7. Looks like a caching problem. It may take a bit to figure out a good workaround. Until then, you'll want to use a Gecko- or Konqueror-based browser to make all the little men spin.

UPDATE II: I've addressed the caching issues. Apple Safari and IE6 won't spin all the little guys at once, so you'll just have to live with only one spinner at a time. However, IE7 has fixed this. Woo-Hoo! They've left almost every other blasted quirk from IE6 in there, but fixed the REALLY CRITICAL THINGS THAT CAN BRING DOWN HUMAN CIVILIZATION, like animated background GIFs and transparent PNGs.

<clap> <clap> <clap> Jolly good show, what?

NOTE II: Opera 8 & 9 is really weird here. If you do multiple connections, it seems to resolve them all at once. I think it's a bug. At first, I thought it was doing all the connections at once, but I noticed that it always resolves all the callbacks at once (in Threaded mode), no matter when they were clicked. The AJAX Queue seems to be the only reliable way of making sure that Opera is working properly.

UPDATE III: I solved the Opera issue. Apparently, Opera ignores "no-cache" headers returned by the target of an XMLHTTPRequest call, so multiple calls with the same URL will result in the response from the first call being propagated to all the rest of the calls. I solved it by adding an "id" parameter to each call.

NOTE III: IN Opera, you don't get any callbacks until Stage 3. In iCab, you don't get the Stage 1 callback, but you do get an immediate Stage 2 callback. In IE, Safari and iCab, you won't get any response text until Stage 4. In Safari, you don't get a response until Stage 2, and that is not immediate (iCab is immediate). The lesson here is that you can't depend on squat until Stage 3, and you can't use response text until Stage 4.

Shim
Shim Shim Shim
preload preload preload