Page 1 of 4   next page »

(This is the second part of a two-part article. The first part appeared in the September 2005 issue of WebSphere Journal.)

Large session objects decrease the JVM memory available for creating and executing application objects. As a result, performance can degrade as the decreased available heap memory leads to more frequent garbage collection.

Another factor is that the in-memory lifetime is always longer than the required usage lifetime, and so the number of sessions occupying space in the Java heap is usually greater than the number of active users. A session expiration time is configurable in WebSphere Application Server and is actually required to avoid a case when a user has to log in again after only a few seconds of inactivity. The release of a session is the responsibility of WebSphere Application Server and the portlet container.

The serialized session size should be smaller than 4KB because WebSphere Application Server can store such sessions with an acceptable database performance overhead, and it takes less time to transfer such sessions over the network. If the session size grows beyond 32KB, the database must use table cells configured for binary large objects that require physical disk access (for most supported databases) if such a session is retrieved or written to the database.

As a first consequence, the creation of sessions should be avoided wherever possible from an application point-of-view. On most public and unauthenticated pages, sessions aren't usually required. Interacting with a portal on such a page is possible via so-called render links that, by definition, don't change the server-side state. Render parameters are maintained by the portal for each portlet for all subsequent requests to that page. To avoid having a JSP create a session by default, the page session directive in the JSP should be set to false:

<@ page session="false"%>

Otherwise, this JSP will create a session if one doesn't exist.

The following Java code fragment shows how you can make sure that an incoming request joins an existing session, rather than unconditionally creating a new one:

PortletRequest.getPortletSession(false)

With the parameter value of false, a session isn't created if no session existed before. If a session didn't exist before, it's probably not appropriate to create one in a portlet just for the sake of storing data in it. As a second consequence, the session should not be misused as an all-purpose data store mechanism. Remember that the goal is to keep the session size as small as possible. If keeping some data in memory is advantageous due to the design of a portlet, then a cache might be the right answer. Cache entries can be scoped with the session ID to keep a relationship between the session and the data that will be kept in memory. Keep in mind that this kind of cache won't be cluster-aware in case of a failover; this is sometimes an acceptable tradeoff. If the data is re-creatable from other data available to the portlet, then the session scope requirement of cached entries is questionable.

In many cases storing large objects in the session can be circumvented by just storing a key in the session and using this key as a reference to look up a larger object in some other data structure. Another option would be to use a more compact representation of the same information and put that object into the session.

Furthermore, the portlet design has to carefully consider what is actually stored in a session. The session is generally intended only for storing the conversational state of the user interaction with the portal application (for example, the contents of a shopping cart in a Web shop portlet). This kind of data is user-specific and can't be recreated by any other means. In WebSphere Portal, this kind of data handling is called a session state.

If session state isn't really required, there are other data storage options available for portlets:

During the action phase of a portlet, render parameters can be set for the portlet's subsequent render phase. A portlet uses render parameters to render its view specific to a specific set of values. Render parameters are maintained by the container request to request, even if interaction occurs with another portlet. In WebSphere Portal, this kind of data handling is called a navigational state.

The PortletPreferences API can be used for storing data for a portlet if such data will be kept across user sessions. Keep in mind that this API isn't intended to replace general-purpose databases. In WebSphere Portal, this data-handling concept is called persistent state.

The PortletConfig API lets a portlet read its configuration, which is provided by the developer using the portlet deployment descriptor; this is valid for all portlet users. The PortletContext API enables the storing of attributes that other portlets in the same application can also access.

Consider other choices than the session for storing data created and used by a portlet. Avoid replicating data into the session that can be re-created from sources other than through user interaction.

Render Links & Action Links
There are advantages to using render parameters other than just to address a specific portlet view.

If an action parameter for a portlet is detected by WebSphere Portal then special action phase handling must be invoked, making it advantageous to avoid using action parameters. However, be aware that processing render links mustn't change the server-side state of a portlet. The only sanctioned way to change the server side state is to use action links - and for a transactional type of request, action links are the best choice.

There are many instances where render links can be used instead of action links. For example, consider a newspaper portlet that can show specific pages with the use of the Previous and Next buttons. Stepping through the newspaper pages doesn't necessarily change the server-side state, which in this case is the entire information contained in the newspaper. To address the next page of the newspaper, it would be sufficient to encode the next page number into the render link for the shown button. The portlet can decide which page to render based on the page number given in a render parameter.

Also, using render links over action links enhances the chance of leveraging a cache infrastructure, be it a browser cache or a proxy cache, since each rendered view is addressed by a separate URL. The URL is the only key used to access a specific generated view in such a cache infrastructure.

Page 1 of 4   next page »