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.
In the past we used HttpRequest to store data that would not be needed past the current request. This allowed us to dispose of unneeded data in a timely fashion. I do not know if you can do the same with webwork or struts. You can access the request in webwork but can not place items into it.
The point you’re missing is garbage collection. Object creation and destruction are the two most expenseive operations in java. if you keep everything is session and use wait for the session to time out to have these items removed you could be placing a lot of information in session that could be destroyed all at once.
I actually do talk about garbage collection.
2K! We have 200K+ and it works just fine. It partly depends on what kind of site you are running.
Of course Brown and Botzum are from IBM, a company that wants to sell you a very expensive product to handle session issues like this. So, perhaps I’ll take their advice with a pinch of salt…