Why does Flex use a single threaded model?

Question

Over the past few weeks I have been building a prototype application using a Flex front end connected to a J2EE backend using blazeDS.

The prototype is an experiment to learn flex and see what its suitability is for a complex trading application requiring a large number of dynamic updates (i.e > 20 a second) via a pub sub type model.

During some lightweight performance tests it's become apparent that I need to use multiple threads to ensure the UI remains stable when receiving a large number of updates from the server. All was going well until I discovered that flex has a single threaded programming model!

From a quick Google it looks as though there are numerous hacks to implement thread like behavior.

I am sure many people must have been faced with a similar problem. Can people let me know:

• Are there any good threading libs that are well maintained etc
• Do other RIA technologies such as silverlight have the same problems.
• Why did abobe implement a single thread model?
• Are there any other tricks I can use to ensure my UI is stable.

Answer 1

I've seen very intensive trader desktop types of Flex apps which work fine in Flex's single threaded model. The reason is that internally Flex apps use async network IO. So the UI doesn't block when you are making the requests. You might be running into limitations with BlazeDS and should perhaps consider something that uses RTMP (like LCDS). RTMP is a more efficient protocol for streaming large quantities of data to the client. Also there are ways to optimize the client-side event handling and rendering code so that you don't bog down the UI. Christophe Coenraets has a few good demos on doing this kind of thing: http://coenraets.org/blog/?s=trader+desktop

What you are trying to do is certainly possible with Flex and there are people who have successfully done it.

However there is a open feature request for this on bugs.adobe.com: https://bugs.adobe.com/jira/browse/ASL-23

Answer 2

If you're having issues with the stability of your UI it might very well be that you're not making appropriate use of the UIComponent model in Flex. It works based off an invalidation / validation model that allows for updates to be deferred until the UI thread is ready to repaint the screen. There's a great presentation on it here:

http://tv.adobe.com/#vi+f15384v1002

Even if your Flex app still had trouble handling 20-30 UI updates per second after those optimizations, what human can actually make sense out data changing at that rate? I would imagine that refreshing the UI once per second would be adequate as long as the full data set was available for calculations and analytics.