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.