Using Session

This topic explains the limitation on WAS, because of which Session needs to used instead of Render Parameter.

In a regular servlet-based Web application, for each request the browser sends, there is one request the server processes. In a Portal environment, the browser request corresponds to two subsequent requests processed by a Portlet - an Action Request followed by a Render Request. Having two separate requests presents a challenge for Web application frameworks such as JSF since browser request processing is divided between the two server-side requests where information and data passes from the Action Request to Render Request. For example, anything that the JSF is configured to keep in "request scope" is destroyed as soon as the Action Request is processed and it is no longer available to the following Render Request. However, from the end-user point of view, there is only one request the browser sent to the server, so anything in "request scope" should persist until the server generates a Response.

There are two commonly used approaches to passing data from Action Request to Render Request: Render Parameters (recommended) - A Render Parameter can be set during Action Request processing and it becomes available to all subsequent Render Requests. Session (not recommended).

In V6.0 of this product, IBM portlet bridge (jsf-portlet.jar) used Session to pass objects between Action and Render requests. While this approach ensured that anything created during Action Request processing was still available to the Render Request, it also had some negative consequences, such as extensive use of Session (resulting in performance loss) and broken Refresh and Back functionality in the browser.

In V7.0, and later, of this product, the new bridge (jsf-portletbridge.jar) used Render Parameters to pass objects between Action and Render requests. Any information and data that the bridge considers important to pass from Action Request to Render Request is put into a Render Parameter during Action Request processing and therefore becomes available to the subsequent Render Request. This approach has a positive impact on overall portlet performance and supports the Refresh and Back button functionality; however, it is not without limitations. The main issue arises from the fact that Render Parameters can only be Strings. Therefore, to pass a non-String object from one request to another using a Render Parameter, requires that the object be encoded into a String and then decoded.

The bridge attempts to pass anything in "request scope" from Action to Render request; however, because of the limitation described, it is not always possible. The bridge can successfully pass an object using a Render Parameter only if the object is either a String or implements Serializable interface. Any non-serialazable object can not be automatically encoded into a String and therefore can not be assigned to a Render Parameter and it can not be passed from an Action to Render request.

Unless the bean implements Serializable interface, it will be destroyed in between the two requests and re-created.

In the V7.0.0.7, and later, a new context parameter in web.xml, is introduced, to make the bridge use the Session instead of Render Parameters. This is crucial for portlet containers that can not handle large Render Parameters, for example WAS. While Websphere Portal has no limit on the size of Render Parameters, WAS has limits, therefore the bridge needs to use Session. You can now use the Session instead of Render Parameter to set context-param com.ibm.faces.portlet.USE_RENDER_PARAMETERS in your web.xml to "false".

For more information, see:

 

Related concepts

Creating Faces portlets and projects

JavaServer Faces portlet applications

 

Related tasks

Creating Faces portlet projects