I have a software design question on what’s the best way to handle a client javascript program that relies in multiple (but mostly consecutive, not simultaneous), short-lived AJAX calls to the server as a response to user interaction [in my particular case, it will be a facebook-GAE/J app, but I believe the question is relevant to any client(browser)/server design].
First, I asked this question: What is the life span of an ajax call? . Based on BalusC answer (I encourage it to read it there), the short answer is “that’s up to the browser”. So, right now I do not have really control of what’s happening after the server sent the response.
-
If the main use for an AJAX call is to retrieve data just once from the server, is it possible to manually destroy it? Would xhr1.abort() do that?
-
Or, the best choice is leave it like that? Would manually closing each connection (if even possible) add too much overhead to each call?
-
Is it possible to manually set the limit per domain?
-
And last (but not least!), should I really worry about this? What would be a number of calls large enough to start delaying the browser (specially some IE browsers with the leak bug that BalusC mentioned in the other question? Please, bear in mind that this is my first javascript/java servlets project.
Thank you in advance
The usage paradigm for
XHRis that you don’t have to worry about what happens to the object — the browser’s engine takes care of that behind the scenes for you. So I don’t see any point in attempting to “improve” things manually. Browser developers are certainly aware that 99.9999% of JS programmers do not do that, so they have not only taken it into account but probably optimized for that scenario as well.You should not worry about it unless and until you have a concrete problem in your hands.
As for limiting the number of AJAX calls per domain (either concurrent outstanding calls, or total calls made, or any other metric you might be interested in), the solution would be the venerable CS classic: add another layer of abstraction.
In this case, the extra layer of abstraction would be a function through which all AJAX calls would be routed through; you can then implement logic that tracks the progress of each call (per domain if you want it to) and rejects or postpones incoming calls based on that state. It won’t be easy to get it correctly, but it’s certainly doable.
However, I suggest also not worrying about this unless and until you have a concrete problem in your hands. 🙂
Update:
Browsers do enforce their own limits on concurrent AJAX calls; there’s a very good question about that here: How many concurrent AJAX (XmlHttpRequest) requests are allowed in popular browsers?
Also, as T. J. Crowder mentions in the comments: make sure you are not keeping references to XHR objects when you are done with them, so that they can be garbage collected — otherwise, you are creating a resource leak yourself.
Second update:
There is a good blog post about reusing XHR here — it’s actually the start of a chain of relevant posts. On the down side, it’s dated and it doesn’t come to any practical conclusion. But it covers the mechanics of reusing XHR well.