RemoteObject Stateful vs. Stateless Classes

Hans asked a while back if I’d discuss stateful vs. stateless classes for the RemoteObject tag. I don’t think I have anything definitive or official to say, but I’ll go through my own thought process as to how I decide what kind of class I’m going to use. First, the default is stateless, so I try to err on using a stateless class unless something compelling comes along to make the class stateful. With that in mind, some reasons to consider stateful classes (not in any order).

  • How long does it take to instantiate an instance of your class? A new stateless class will be instantiated every time you call any method, so instantiation should be cheap. Now we all know that instantiation is never cheap, so in the future I could see us supporting some sort of pooling mechanism where classes would need to be obtained and released. Anyway, if it takes a long time to instantiate your class, it might be worth keeping it stateful assuming it doesn’t also hog massive memory.
  • How many users will be logged in at once? If the number isn’t too high, perhaps you can save some instantiation time by making the class stateful. Too many users at once and you’ll be taking up memory, especially if your class is holding references to other classes and preventing garbage collection.
  • Are you load-balancing your server? This would strike me as a reason to try to avoid stateful classes as you’d then need to transfer this class across to another server as well. However, as long as your class can be load balanced by your app server if stored in a session variable you can set it as stateful.
  • How much information is needed across operations? For example, does some sort of token need to be passed to every operation that your RemoteObject will then pass to a commerce server? Are there multiple tokens to pass? A stateful class would allow you to set a token once, then not have to pass it through each method (which saves a little space and time on the wire). However, you then pay the expenses mentioned above of space on the server (memory). What if you stored that information in a 3rd place, like a database or regular file and accessed using a shorter token? If you were passing a lot of information a stateless approach means a lot of network traffic and a stateful approach means a lot of server memory . The database approach might be a reasonable compromise, however the cost here is the database access for every operation (and any network costs between the database and your app server).

I think I could probably keep building on this list, but you are hopefully seeing a pattern. Like most optimizations, you are making a choice between time and space. You generally save time by having a stateful class which means potentially less network traffic between Flash client and app server and fewer instantiations. However the expense is that you end up using more memory on the server as every RemoteObject and relevant data is stored for each session. Sometimes the choice will be obvious, and sometimes you’ll need to run tools like profilers and heap analysts to give you more data to reach a decision.If anyone has stories of how you’ve made your own decisions feel free to share. And maybe some other folks who’ve done more work with the RemoteObject at Macromedia will jump in as well.

2 Responses to RemoteObject Stateful vs. Stateless Classes

  1. Barry Netu says:

    Matt,The more I learn about Flex that more excited I get about using it. The one big hesitation I have though is the inherent flash load time that I see even for simple UI elements. Say you have a page with 1 text field. Even after the mxml compiles to a swf, the load time for a user just hitting it is not good, compared to the millisecond response time of a HTML text field, for example. So anyway, can you reveal anything that your team is planning to resolve this issue? In my mind, that’s the big sticking point.

  2. Matt says:

    Well, for the single TextInput you’re right that HTML will be much faster to startup. The Flex application model includes a lot of functionality that you wouldn’t need in that scenario so we don’t want to compete. It’s when the app gets more interesting that the startup time becomes less of a factor because of the other benefits. With that said, we’re always working on performance. The next release of Flex has some real performance improvements including startup time. The next Player release will hopefully also bring a significant performance boost.