Comments on: Keeping Track Of State In Asynchronous Callbacks

By: Generation 5 » Converting A Synchronous Program Into An Asynchronous Program

Thu, 14 Aug 2008 16:30:09 +0000

[...] it’s useful for f() to correspond to an object, of which the fN() functions are methods. [1] [2] [...]

By: Generation 5 » Getting back to the UI Thread in Silverlight 2 Beta 2

Generation 5 » Getting back to the UI Thread in Silverlight 2 Beta 2 — Thu, 26 Jun 2008 14:00:17 +0000

[...] but what if you want to pass some parameters to the function that updates the UI. The usual three choices for passing state in asynchronous applications apply, but it’s particularly easy and fun to use a closure [...]

By: admin

admin — Fri, 06 Jun 2008 02:43:00 +0000

Well, in a perfect world, we’d design the client-server protocol so that all the information that the client needs to handle a UI event comes in one big batch… Then you don’t need to worry about choreography, error handling and all those hairy issues. See this article.

In the real world we need to talk to server apps that we don’t control… So we have to deal with those issues.

By: Thomas Hansen

Thomas Hansen — Thu, 05 Jun 2008 19:18:06 +0000

@admin
Yes I totally agree, in fact I by “chance” stumbled into the problem when adding up a timer onto my page and then frenetically clicked a button at the same time and by accident discovered that sometimes the ViewState went completely *bananas* and the page became in an “undefined state”…
Then I spent more than a WEEK in fact re-creating our core to give support for sequential requests…

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…

By: admin

admin — Wed, 04 Jun 2008 19:09:02 +0000

@Thomas, your solution is a correct way to use AJAX and makes a lot of sense.

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!

By: Thomas Hansen

Thomas Hansen — Tue, 03 Jun 2008 16:44:40 +0000

Or you could use an Ajax Framework that queues up the requests which is the only sane thing to do when you have a server/client solution and waits for the previous one to finish before creating a new one
(Hint; follow my link)
Nice blog though, and VERY important to be aware of, though probably less than 1% of ASP.NET AJAX developers are…