In the real world we need to talk to server apps that we don’t control… So we have to deal with those issues.
]]>I think that yes you are right, there might exist some extreme scenarios where it makes sense to have more than one running at the same time, though if they’re both running towards the same server, you will get OTHER problems (2 HTTP connections per IP constraint in most browsers)
So I think probably if you are going to use them you would normally have them first of all run towards different IPs (servers) then also in addition it would be *WISE* to make sure they’re not updating the same parts of the UI…
Though for us (Gaia Ajax Widgets) this is completely abstract and would never happen unless people completely mis-used our framework in ways it was never intended to be used for…
On the server creating more than one request towards OTHER servers (WebServices and so on) asynchronously though is a totally different story…
.t
]]>There is one case where it does make sense to generate concurrent requests, and that’s when information from several requests is going to be combined. Running requests in parallel can greatly reduce the effects of latency — in many cases this can make a large difference in performance (much more than two.)
I think most people doing AJAX in Javascript can get away with being ignorant about concurrency problems because they’re bolting simple behaviors onto an HTML page: when something does go wrong, the situation is usually recoverable. I know that I programmed a little AJAX here and there for years and never experienced concurrency problems — then I built a GWT app!
People working with tools like Silverlight, GWT and Flex (as well as a few brave Javascript Ninjas) are building larger applications that are going to have more problems. It’s time to spread the word about the problems and the solutions!
]]>