IBM BS029ML Self Help Guide - Page 50

2.5.8 Portlet application JVM considerations Portlet applications, like any other Java based applications, when deployed into WebSphere Portal Server, reside within the same JVM and therefore share resources, such as JVM heap space and the Web container thread pool. In this way, Portlet applications are limited to the following constraints: Shared JVM resources may become constrained if one Portlet application experiences runaway memory consumption. The JVM cannot be tuned specifically for any one Portlet application's requirements. Individual Portlet applications cannot be guaranteed a QoS above that of the WebSphere Portal Server proper. Poorly written Portlet applications cannot be isolated and potentially run the risk of impacting other Portlet applications deployed within the Portal. Of course, Portlet applications that perform and scale are not accidental. They are the result of proper development and processes that include iterative performance verification and re-verification during the entire application life cycle, including post-production maintenance. 2.5.9 High availability and HTTPSession failover User interactions with WebSphere Portal Server are maintained through the use of a HttpSession. This provides a way to preserve data across multiple pages or requests on an individual user basis. The failure or outage, either scheduled or unscheduled, of a WebSphere Portal Server cluster member will result in the termination of the user's HttpSession. As such, it is possible to enable HttpSession failover support to facilitate maintaining a user's session when requests are failed over to a subsequent cluster member. However, arguably one of the most misunderstood subjects is that of the HttpSession. First, for WebSphere Portal Server, the HttpSession should not be confused with the LTPA token. It is the actual LTPA token and not the HttpSession that maintains the delegated authentication credential. Without such a credential, a user would be challenged to reauthenticate with the solution each time he or she initiates a subsequent request. The HttpSession is also subject to an inactivity timeout. However, it is possible to configure Portal Server to create a new HttpSession should the initial HttpSession expire. Secondly, the use of the HttpSession as a mechanism within WebSphere Portal Server for persisting user attributes for the duration of a user's session is generally discouraged, as there are alternative methods for achieving the same goal more efficiently. It should be noted that HttpSession failover does not provide transaction failover. In-flight transactions would need to roll back in the event of a cluster member outage, regardless of whether HttpSession failover was enabled or not. It is, however, worth remembering that the underlying WebSphere Application Server instance of WebSphere Portal Server includes a Transaction Manager that can be leveraged. Finally, it follows that the size of the HttpSession object and the size of the permissible Java heap directly influence the number of users that Portal can concurrently support. Of course, scalability issues can be addressed by WebSphere clustering. 36 IBM WebSphere Portal V6 Self Help Guide