WebSphere Application Server Extensions

WebSphere Application Server provides a number of extensions to the programming model and administrative model. The extensions that affect the programming model are discussed here. Other administrative model extensions are discussed in Chapter 14.

Extension Packages

WebSphere Application Server provides the following presentation-related APIs in the base application server.

• com.ibm.websphere.servlet.session.IBMSession interface
  Extends HttpSession, for session support and increased web administrator's control in a session cluster environment.

• com.ibm.websphere.servlet.filter package
  Provides classes that support the servlet filter object.

• com.ibm.servlet.personalization.sessiontracking package
  Records the referral page that led a visitor to your web site, tracks the visitor's position within the site, associates user identification with the session, and provides session clustering support.

• com.ibm.servlet.personalization.userprofile package
  Provides an interface for maintaining detailed information about your web visitors and incorporating this data in your web applications, so that you can provide a personalized user experience. You can make this information persistent by storing it in a database.

• com.ibm.websphere.userprofile package
  Enhances the user profile.

See http://www.ibm.com/software/webservers/appserv/infocenter.html for a full description of the APIs.

HTTP Sessions

HTTP sessions and HTTP session state management are an extremely important part of web applications. The following sections explore the implications of session extensions to persistence, scalability, and security.

Session Cache

WebSphere Application Server provides cached management of HttpSession instances. In certain circumstances, such as exceeding the cache size, the session manager may not manage the session. Instead, a dummy session will be created. An application can check whether or not this has occurred by using the IBMSession interface isOverFlow() method. It returns true if the maximum in-memory session count is exceeded and overflow allowed has not been configured.

Session Persistence

Clustered environments, which need to share state, and failover capabilities all require the ability to persist the state of the session. WebSphere Application Server provides for persistent sessions, but all objects added to the session state must implement the java.io.Serializable interface if persistent session state is required. Session persistence also supports persisting the following non-serializable J2EE objects:

• javax.ejb.EJBObject

• javax.ejb.EJBHome

• javax.naming.Context

• javax.transaction.UserTransaction

However, UserTransaction objects in the runtime will not persist open transactions and re-establish them across servers. Also, any transaction must be started within the execution of the service() method and it must be completed before the service() method returns, otherwise the transaction will be rolled back.

Most of the time, the session manager will control when it is appropriate to save the session state. WebSphere Application Server provides a number of policies for controlling this. However, there's also a manual policy that allows the application to control when the session state is persisted. The application must use the com.ibm.websphere.servlet.session.IBMSession interface's sync() method to tell the runtime to persist the state.

One last consideration is the size of the session state. By default, persisting a session to a database will result in the entire state being serialized to a single row. If the state exceeds 2MB, then a single row cannot be used. WebSphere Application Server provides multi-row persistence capabilities, but not without some overhead cost. Using multi-row session state persistence allows each attribute to be up to 2MB in size and the total size to be unlimited. It also allows individual attributes to be retrieved on demand rather than the full state. Inter-object references should be kept to a minimum, because retrieval of the individual attributes will not reconstruct the object reference graph to the original graph. Each attribute of the session will have its own copy of each referenced object. Cyclic references will be broken causing duplication of objects in memory. One more multi-row persistence policy, Write contents, has an implication on the programming model. A choice can be made of Write changed attributes or Write all session attributes. Single row session persistence ignores these policies and persists everything, but the multi-row persistence honors them. When multi-row persistence is used in conjunction with Write changed attributes, the session manager will persist only those attributes that are placed/replaced in the session using the session.setAttribute() method. If an attribute is retrieved from the session and subsequently modified without calling session.setAttribute(), it will not be persisted to the session database. Be aware that the combination of large session states, large cache sizes, and long session timeouts can be a deadly combination for an application server. Note, sessions should always be invalidated when they are not needed anymore.

Session Security

WebSphere Application Server performs secure access checks for the session when security is turned on. When the session is created, the current user ID is associated with the session. On subsequent requests, a check of the request ID is made with the session's user ID. If they don't match, a com.ibm.websphere.servlet.session.UnauthorizedSessionRequestException is thrown. The session's user ID can be checked with the com.ibm.websphere.servlet.session.IBMSession interface.