Cameron Purdy

Subscribe to Cameron Purdy: eMailAlertsEmail Alerts
Get Cameron Purdy: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Article

The Management Option

The Management Option

WebSphere provides a number of out-of-the-box session management options, including a new in-memory replication option in WebSphere 5. Successful use of session management requires some engineering foresight, and optimal use of session management requires an understanding of the options that WebSphere provides.

On the engineering side, the rules for successful session management are simple:

  • Make sure that all attributes that are put into a session are serializable. This allows you to later use distributed sessions if necessary for scalability or failover reasons.
  • If you get a mutable attribute out of the session and change it, make sure that you explicitly put it back (using the setAttribute method) so the container knows for certain that the session attribute was modified. This is unnecessary for nondistributed sessions, or when using advanced session products, but you should still always follow this rule.
  • Use the session attributes only for user- or session-related data, and never for data that can be stored or cached globally. Sessions used for global data end up increasing significantly in size, and the data is often duplicated across many sessions, thus wasting memory.
  • Keep track of how big your sessions are, and try to minimize that size. Some of the session management options work acceptably only for small sessions.
  • You will most probably have to do some extra work to support URL encoding for session identity. URL encoding is often used as a backup approach for session identity when session cookies do not work, which can happen when for example cookies get rejected by a browser's privacy settings. (For more details on how to support URL encoding, see tinyurl.com/33dsg.)
  • Remember that an HTTP session is not guaranteed to be there, and that it is not in any way guaranteed to be transactionally consistent. For example, if a server fails, the session - or part of it, or even just the most recent updates - may be lost. The application must be built in a resilient way, expecting that such things could happen.
When configuring WebSphere, the key to obtaining HTTP session management nirvana is, like most things in software, knowing the requirements before deciding on the solution. Further, like almost all other tasks in software, the optimal solution is usually the simplest one. What are your requirements in the following categories?
  • Session tracking: How do you want the session identity to be managed by the client? Should it be invisible in a browser cookie, or encoded into the URL via URL rewriting? WebSphere supports both cookies and URL rewriting. (There is an additional option for SSL-based session identity, but it usually requires the additional use of a cookie or URL rewriting to make it work.)
  • Session size: How much data is in your HTTP session object? Is it tiny (less than 250 bytes including all names and values) small (less than 2KB); medium (less than 50KB); large (less than 500KB); or huge (above 500KB)? The larger the HTTP session object, the fewer the choices that are practical - or even possible.
  • Session persistence: Should the session data be stored using a central store, such as any JDBC database? This may allow the session data to survive the failure of a server, or even the temporary shutdown of the entire application (i.e., all clones). Also, if the session is to be persisted, what is the tolerance for losing data? WebSphere supports an option that allows data to be lost in order to provide more acceptable performance for session persistence; you can choose whether you want better performance (the TIME_BASED_WRITES option) or more surety that the data is saved (the END_OF_SERVICE option).
  • Session mobility: In a cloned or other multiserver environment, should WebSphere allow a session that was last accessed on one server to be accessed by another server? This is called session mobility and is usually the basis for session failover.
  • Session failover: In a cloned or other multiserver environment, should session information survive the loss of any single clone or server? This can be accomplished in WebSphere by using either session persistence or memory-to-memory replication of sessions.
Ask yourself if you truly need session failover capability, because it is the most expensive option in terms of computing resources, and will require either the memory-to-memory or the session persistence option. If you need session persistence, ask yourself if you can tolerate the potential loss of data on failover that the TIME_BASED_WRITES option allows to occur. If you are fortunate, you don't need any of those options, and can simply use nonmobile nondistributed nonreplicated, nonpersisted sessions.

Last, there are a few downsides to watch out for, particularly with respect to the size of the HTTP session object. Even with new options such as memory-to-memory replication, WebSphere staff are careful to point out the importance of keeping your sessions small (from tinyurl.com/24cve).

So, make sure you follow the engineering rules for supporting session, keep your sessions small, and know for certain what availability options you actually require.

More Stories By Cameron Purdy

Cameron Purdy is Vice President of Development at Oracle. He has over 16 years of experience growing software companies and leading product development efforts. Formerly he was Co-Founder & President of Tangosol, a startup company that specialized in enterprise Java component development software. A software visionary and an active member of the software community, he is a contributor to the Java and XML specifications, is co-author of a component-based development patent with Dr. Gleyzer.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.