If you’re using a MVC web framework, such as WebWork or Struts, you might have had to store long-term state in your Http Session. At my job, since we do not use Stateful Session Beans, this is common. So, the solution in place was designed to do the following:
- Allow requests to transport state to subsequent requests without having to add each trivial (String) value as a hidden field on the view.
- In addition to the above, the non-trivial values do not work well as hidden fields.
- Discontinue the manipulation of multiple JavaBeans in the view. Depending on the complexity of the screen, and the number of beans involved this could become overly-complicated.
Moving away from the items listed above, and providing a cleaner and reusable way to transport long-term state between requests is fine. The issue I am most concerned with is the size of the Http Session. I understand that it’s mid-2005, and memory is not as large and expensive as it once was. However, this shouldn’t give developers license to just shove things into the session, and hope for the best. Here are some reasons why:
- Unused objects will sit in the Session until the session is invalidated.
- Garbage collection will never occur for the unused objects mentioned above.
- Based on the application’s complexity, this could lower performance.
- In general, you keep your session size as small as possible; Brown and Botzum say 2K is the suggested size, but I think that’s unrealistic.
IBM’s Brown and Botzum, suggest using transient for fields that will not be persisted, and having all items being added to the Http Session implement Serializable. This makes sense, but what if you are handling Hibernate objects? The transient keyword will not help much. Aside from reloading data each and every time you need it, the best option seems to use a StateBean of some sort. However, instead of just solving the basic problems of transporting long-term state, this StateBean should provide the following:
- The ability to decipher between event sensitive and insensitive state.
- The ability to set a space limit for event sensitive state.
- When new state is being bound and the space limit has been reached, remove old event sensitive state so that unnecessary heap use does not occur.
The limit of event sensitive state should be fairly small, allowing for just a handful of unrelated use-cases to occur before stale state is removed. If implemented properly, there should be at most one StateBean per Http Session. Keep in mind, if a developer wishes to place items that should be easily accessible during the entire Session, they still can.
