|
J2EE Best Practices & Performance Tips |
|
|
Written by sunil boricha
|
|
Page 11 of 13
10. When using HttpSessions, store only as much state as you need for the current business transaction and no more.
Enable session persistence.
HttpSessions are great for storing information about application state. The API is easy to use and understand. Unfortunately, developers often lose sight of the intent of the HttpSession -- to maintain temporary user state. It is not an arbitrary data cache. We have seen far too many systems that put enormous amounts of data -- megabytes -- for each user's session. Well, if there are 1000 logged-in users, each with a 1 MB HTTP session, that is one gigabyte or more
of memory in use just for sessions. Keep those HTTP sessions small. If you don't, your application's performance will suffer. A good rule of thumb is something under 2K-4K. This isn't a hard rule. 8K is still okay, but obviously slower than 2K. Just keep your eye on it and prevent the HttpSession from becoming a dumping ground for data that "might" be used.
One common problem is using HttpSessions to cache information that is easily recreated, should it be necessary. Since sessions are persisted, this is a very expensive decision forcing unnecessary serialization and writing of the data. Instead, use an in memory hash table to cache the data and just keep a key to the data in the session. This allows the data to be recreated should the user fail over to another application server. (See [Brown2] for more.)
Speaking of session persistence, don't forget to enable it. If you do not enable session persistence, should a server be stopped for any reason (a server failure or ordinary maintenance), any user that is currently on that application server will lose their session. That makes for a very unpleasant experience. They have to log in again and redo whatever they were working on. If, instead, session persistence is enabled, WebSphere will automatically move the user (and their session) to another application server, transparently. They won't even know it happened. This works so well, that we have seen production systems that crash regularly due to nasty bugs in native code (not IBM code!) yet provide adequate service.
|
Java Articles 
