A session is a space in memory that the server side preserves from one request to another. UNICOM^® Digital Transformation Toolkit (UDTT™) uses two types of sessions to realize multichannel support: channel sessions, which are maintained by the channel (such as the WebSphere servlet engine), and application sessions, which are maintained by the application through the application session table. The design of the multichannel support implementation requires that a channel session be created if a channel session is to be maintained between the client and the server. In addition, the component provides the ability to manage one or multiple concurrent sessions between the client and server per channel session, and these are called application sessions and application subsessions.

Each channel session has an associated context and each of the requests processed under this session access the context hierarchy through this session context. An application subsession is a session within a channel session. The application subsession also has a context. This context is automatically chained to the session context so that each request running in the application subsession has access to the application subsession context and the application session context. An application shares the same session context with the rest of the applications running under the session but each of them has its own application context. For example, the session context holds the data and services that are exclusive to Ken, a bank clerk, and there is an application subsession for each of his current customers to hold the data for that customer. Each application subsession is isolated from the others but they all have access to the information in the session context and higher in the context hierarchy. This allows Ken to interrupt performing operations for one customer so that he can perform operations on behalf of a different customer. The first customer's environment (application context and session) remains untouched by anything in the second customer's environment. However, both environments can access information at the session context level such as Ken's user ID and password.

The relationship between a single channel session and application sessions is a one-to-many relationship, although there will usually be one application session per channel session, sharing their unique identifier. Application sessions are maintained by the application and used by the toolkit, to provide the application with the ability to manage them isolated from the specific channel session's management implementation. Application sessions link channel sessions with application context instances. Thus, the multichannel support implementation knows what context to use to link a specific request coming from a concrete channel session. Any request coming for a given session is handled under the session context.

When more than one operation request comes from the same client workstation under the same session but for different subsessions, the IDs for the channel session and the application subsession are used to create the context hierarchy for the operations.

Application subsessions provide the ability to manage multiple or concurrent sessions under the same session between the client and server. Application subsession support is implemented by the Java and HTML Channels only. A solution may or may not use this feature.

Application subsession support makes use of the application session table within the toolkit. This table is a keyed collection of session entry elements. The application session associated with the channel session is the parent element for all application subsession elements. This creates a parent/child relationship so that if the channel session is removed from the application session table, all application subsessions will be removed.

Multichannel support ensures that both the channel session and the application subsessions are managed between client requests using the IDs, and fulfills this requirement for devices that use the HTTP communication protocol.

The following is an example of a typical session entry in the application session table. Note that the session only provides a single level of nesting for application subsessions. The current context that is maintained in the session table by the session or application subsessions should be managed by the application according to the solution flow.

The following schematic diagram shows the role of the session ID and application subsession ID in building the operation context hierarchy:

The diagram shows that each session identifier is associated with a specific context instance. This relationship is kept in the application session table, which is updated by the application and read by the infrastructure.

For multichannel support, a channel session is always required between the client and server. All implementations of the multichannel architecture use channel session management, which provides a way of keeping track of the use of the channel that is isolated from an application session. The channel session can be used to build the correct context hierarchies for a series of related operations coming from different applications on the same or different clients.

Channel session management must be realized either by managing the sessions of a channel or by a customer-specific implementation. The advantage of having the channel manage its sessions is that session management may be part of the communication protocol, allowing the channel driver to benefit from open industry standards (for instance, HTTP session management provided by the servlet engine). In this case, the channel driver is required to fire an event for which the CSServer service is the registered listener. The CSServer then fires an event for which the application is a registered listener. This design provides a consistent interface for the application to become a registered listener of events regardless of the session management implementation. To facilitate realizing this design, the toolkit provides the following utility classes and interfaces:

The toolkit provides the following functionality for devices using the HTTP communication protocol to support session management for a servlet engine such as WebSphere:

For all devices, the toolkit provides an implementation that can be used by an application if the channel does not provide for session management or the particular application does not require session management. For example, if the browser does not have cookies enabled and you are using the HTTP communication protocol, neither the HttpSession nor the servlet engine session management can be used. To cover this scenario, the toolkit provides the following optional parameters in the CSServer element tag:

These parameters allow the multichannel support implementation, and in particular the Client/Server Service (CSServer), to use the application session table to manage sessions. If the parameter does not exist in the CSServer element tag, or the cookies parameter in btt.xml is set to true, the multichannel support implementation will not manage the inactivity timeout, since it will be managed by the specific channel session manager implementation.

The following entry in the toolkit services definition file on the server (dsesrvc.xml) specifies that the session will time out after 10 seconds (10,000 milliseconds) and the thread that looks for expired sessions will awake every two minutes (120,000 milliseconds):

To provide a way of cleaning up the resources allocated by an application subsession independent of the expiration of its parent session, the CSServer tag also has the appSessionTimeout attribute. This optional attribute defines how long an application subsession remains without processing any request before the CSServer service fires the CSInactivityClientEvent timeout. The following is an example:

The Client/Server Service fires a CSInactivityClientEvent to notify the registered listeners that a session has expired, and it is the responsibility of the application implementation to remove the session entries from the application session entry table and perform any other cleanup of the sessions. To specify whether the expiring session is the main session or an application subsession, the toolkit sets the appSessionId attribute of the event, either to the ID of the expiring application subsession or to null if the main (channel) session is expiring. The application must check the value of this attribute to determine whether it must perform a session or application subsession housekeeping process.

If a valid inactivity timeout is specified for the Client/Server Service and the timestamp of the application session is null, the toolkit does not signal an event. Instead, it is expected that the event will be raised by the channel implementation of session management.

The application session entry information is maintained in local memory and is not persisted, unless session persistence is enabled (see Persistence schema for load-balancing and failover support). The application session entry table is maintained by the Context class as a keyed collection of the following elements, which are listed in the application session table for each session:

In V8.2.0.2 or later, the ISessionCallBack interface is provided to help you monitor the session status. You can implement the callback APIs of the ISessionCallBack interface according to your business requirements to improve the system performance.

The ISessionCallBack interface is provided to monitor the session status changes when the session is created, removed, updated, retrieved, and timeout. You can implement the callback APIs in the ISessionCallBack interface to deliver distributed cache management. You can capture the session status changes and manage the sessions in the cache by taking the actions that you implemented for different session statuses. In this way, the data granularity for session management is improved. By implementing the ISessionCallBack interface, the following advantages are supported to improve your system performance.

The ISessionCallBack interface contains the following callback APIs:

Use this interface to monitor the session status change when a session is created, and implement your response actions.

Use this interface to monitor the session status change when a session is removed, and implement your response actions.

Use this interface to monitor when the session idle threshold is reached, and implement your response actions.

Two levels of session timeout is defined in the ISessionCallBack interface. The first level with the lower timeout threshold value is defined to monitor when the session is idle for a specified duration. You can use this interface to monitor the idle level of the session timeout. When this interface is called, The idle status of the session entry is true.

After this interface is called, monitoring of processor timeout is paused until the session becomes active.

Use this interface to monitor when the session timeout threshold is reached, and implement your response actions.

Two levels of session timeout is defined in the ISessionCallBack interface. The second level with the higher timeout threshold value is defined to monitor when the session is timeout. You can use this interface to monitor when the application is timeout.

Use this interface to monitor when the context of an idle session is retrieved, and implement your response actions.

After the onIdle interface is called, the idle status of the session entry is true. The system users can still change or swap out the context. To ensure that the context exists and is usable, the onRetrieveIdleContext interface is called when the context of an idle session is retrieved.

Use this interface to monitor when the session data is changed, and implement your response actions.

Use this interface to generate the session ID, and implement your response actions.

The old default session ID is replaced with the new session ID that is generated by the onGenerateSessionId interface.

Use this interface to monitor when the session is retrieved by using the session ID before failover, and implement your response actions.

Use this interface to monitor when the sessionEntry timestamp is changed, and implement your response actions.

For details about implementation of the callback APIs of the ISessionCallBack interface, see Implementing the callback APIs of the ISessionCallBack interface.

When a session spends a given amount of time without processing any request, the session times out. When this occurs, the data associated with the session, both toolkit internal data and application data, remains stored in memory. The application must clean up the session resources.

The session management provided by the toolkit can use cookies or not use cookies. This is controlled by the following setting in the toolkit configuration (btt.xml) file:

If the cookies field is set to true, WebSphere Application Server performs session management. When the toolkit establishes a session, it creates an HTTPSession object. This causes WebSphere to become aware of the session, and the application can then use WebSphere's session capabilities. The toolkit delegates to WebSphere the detection of session expiration. If the cookies field is set to false, the toolkit performs session management internally.

The toolkit lets the application decide what to store in a session and how to store it. The toolkit only requires that the session have an entry in the session table and a context. Once the session has been established, the application executes an operation to add the session entry to the sessions table.

While the toolkit does not provide a session startup operation, the sample applications provide examples of ways to implement one according to the concrete channel implementation being used. The operation establishes the session by placing an entry in the session table and by creating a context for the session. Once this occurs, the toolkit is aware of the session. The following diagram shows a context and its entry in the session table:

The session context and the session entry can store any application information and the session context can initiate services. The application must be aware of this data and any running services when handling the expiry of the session.

When a session spends a given amount of time without processing any request, the session times out. When this occurs, the application must clean up the resources allocated for this session as part of the session expiry. See Managing session for information on how to configure and handle application sessions.

An application subsession is a session within a session. The application subsession also has a context. The toolkit automatically chains this context to the session context so each request running in the application subsession has access to the application subsession context and the session context. An application shares the same session context with the rest of the applications running under this session but each of them has its own application context.

The application subsession context stores only the following three toolkit internal fields:

The dse_sessionId is the application session ID. The other two parameters are for HTML processor management because memory usage related to HTML processors is associated with an application subsession instead of the session.

The application subsession has a freely accessible context for the application to retain any information and service definitions. The application should clean up all of this information when the subapplication session is no longer available. This cleanup can occur as part of the application subsession expiry or as part of a specific application session cleanup occurring during session expiration.

Note that application subsessions are always associated with only one session. When an application session expires, it is the responsibility of the application to perform any needed cleanup for the session and all the application subsessions associated with it. Once an application session has expired, the toolkit treats all its application subsessions as expired also, and no longer checks the application subsessions for timeout. This can cause a problem if an application session expires and the application does not clean up its subsessions, because it means that the application will never be notified of the expiration of those subsessions.

See Managing session for information on how to configure and handle application sessions.

HTTP session identity and clustering support are implemented only in HTTP channels in conjunction with WebSphere Application Server. The following HTTP channels are provided:

The toolkit uses the following two approaches to handle session identification in an HTTP environment:

Mechanisms are provide to exploit the benefits of each of these approaches in order to cope with the following requirements:

No matter which session identification approach is used, it is the application's responsibility to perform the tasks required to meet its requirements. The toolkit does not provide fixed or default mechanisms to do these tasks because these are dependent on the specific solution environment. However, a set of infrastructure mechanisms are provided, and these are described in the remainder of this section.

The toolkit saves a reference to the session object that currently manages a session in the application session table. The session object can be either a DSEChannelSession object or an HttpSession object. The com.ibm.btt.base.SessionEntry class has the following methods to get and set this object:

If the cookies parameter is set to true, the getSessionObject() method returns an instance of HttpSession. If it is set to false, the method returns an instance of DSEChannelSession. SessionEntry also provides getter and setter methods for retrieving and changing the locale used to localize messages on the client.

A cluster is the binding of two or more Virtual Hosts that reside on separate nodes, such that each Virtual Host runs servlets across all of the nodes and processes sessions on any one of those nodes. The implementation of clustering in WebSphere Application Server allows for failover, which preserves session data integrity and the common pool of sessions in the event of a system failure in one or more of the clustered Java virtual machines (JVMs) running servlets within a WebSphere Application Server Virtual Host group. It also allows for load-balancing, whereby the session workload is distributed among the Virtual Hosts comprising the cluster.

WebSphere Application Server maintains session clusters using a database. In a clustered environment, the session may be accessed on any one of the Virtual Hosts in a cluster; which one is actually accessed will be transparent to the end user. During the processing of a session transaction, if the Virtual Host fails for any reason during the WebSphere HttpSession transaction then the update to the database does not occur, but the common pool of sessions continues to function (including the session being processed during the failure, minus any updates made during the failed transaction). For non-catastrophic failures (for example, when the virtual host remains functional), any changes made to the session during the transaction attempt are rolled back and the session reverts to its state prior to the start of the transaction. Otherwise, once the transaction has completed and the changes are committed, the session is still accessible regardless of the failure of an individual node.

UNICOM^® Digital Transformation Toolkit (UDTT™) provides base infrastructure persistence functionality for high availability solutions (24x7) using a load-balancing mechanism among a set of server clones, each running a toolkit-based environment. The functions include the following:

The WebSphere family of products provide load-balancing, failover, and session affinity. An application running in this kind of environment must be properly designed to use these features. For example, requests can be routed to any of the available nodes or clones that contain the server side logic of the application. This means that the solution must not make any assumptions regarding the availability of previous state information in memory, and instead must store the required state so that it can be shared across many requests in a data store. Thus, when a server clone processes a request, it saves the state information into a database to allow other server clones to restore the information to process another request. In the toolkit environment, you configure WebSphere to use multiple rows of server clones to get better performance. The objective is for the use of multiple server clones to be transparent to the client while providing superior performance and availability. The actual behavior depends on the proper configuration of WebSphere, such as cache settings and the policy for session affinity, and the configuration of the toolkit itself.

Refer to the WebSphere documentation for information on properly configuring the WebSphere platform for multiple server environment support. For the toolkit, see Configuration for session persistence and session affinity.

In UDTT, multichannel support for persistence includes the following main areas:

Whereas the context of the session applies to any HTTP client (such as a Java client, an HTML client, or an XML client), the information associated with the processors applies only to the HTML clients requiring the Flow Processor to control the navigation of the user interface.

The toolkit provides components that exploit the features of the standard HttpSession to get and put serializable objects, including toolkit contexts. This provides a way to save and restore any data belonging to a context instance and its child contexts. However, the parent hierarchy of the context cannot be saved and restored.

Any servlet engine providing session persistence based on the standard Java Servlet API can associate the persistence of the data objects with an HTTP session. For the toolkit, WebSphere Application Server is the servlet engine that provides this behavior. The toolkit delegates actual database management to WebSphere instead of providing its own persistence mechanism.

When a toolkit server clone receives a request, WebSphere restores the HttpSession and retrieves the data for the objects associated with the session (such as processors) in previous requests. The toolkit infrastructure only re-instantiates these objects when it gets the object names from the session to create the session context. The toolkit infrastructure associates the session context with the HttpSession and with as many processor contexts as required during the life cycle of the session. It only repopulates a processor context when the associated processor is re-activated.

The WebSphere cache policy declares that WebSphere only stores an object in the database when the toolkit infrastructure performs a "put" of the object during the request process. The toolkit infrastructure performs a "put" of the session context when it returns control back to WebSphere after processing the request. Note that the infrastructure only "puts" objects associated with the active processor (the processor performing the request), thus not overriding other processors that may have been rerouted to another parallel server clone.

The following picture shows the contexts within the toolkit multichannel architecture:

You can affect the overall performance and behavior of the system by enabling or disabling session affinity. If session affinity is enabled, a client's requests are always passed to the same server (in a group of cloned servers) once a session has been established. You must properly configure WebSphere and the toolkit so that both have session affinity either enabled or disabled. (For the toolkit, see Configuration for session persistence and session affinity.)

Whether to enable session affinity is a decision that must be made based on the overall architecture of a solution. Typically, enabling session affinity is the best choice when some state information must be kept across several requests. In such cases, session affinity usually provides better performance and makes implementing the solution easier, while still providing the failover feature by rerouting the requests to another server when the active one crashes.

If it has been configured with session affinity enabled, the toolkit uses the following schema when it processes a request:

If it has been configured with session affinity disabled, the toolkit uses the following schema when it processes a request:

The API implementing session persistence is at the channel driver level. The class CSReqServlet is an implementer of ChannelDriver that is specific for the HTTP protocol; ChannelDriver is extended by all the servlets currently provided by the toolkit. Customized solutions may extend these classes, overriding the following methods if necessary:

Applications must explicitly handle data belonging to contexts higher in the context hierarchy than the session context. The design of a solution must account for these data elements, which may be shared by different clones.

A possible solution is to use special Context objects to persist this data in a database and restrict access to this data to avoid performance degradation. You can achieve this by extending the Context class and defining a new tag for the new context elements in a parent of the session context. Other alternatives, such as the propagation of data changes among the clones for those data elements that do not change very frequently, can also be applied to get better performance for read-only accesses. A cache is usually a good implementation for this kind of situation.

To clean data in the servers related to a session, you can use the WebSphere and toolkit session inactivity timeout mechanisms. The WebSphere mechanism removes the database entries for the sessions that exceed the WebSphere timeout. To clear the information kept in memory, occurring mainly when session affinity is enabled, you can use the toolkit mechanism. In this case, you can use the handler registered to the CSServer service inactivity timeout event to clear information in the application session table associated with expired sessions. You can also use this handler to access the HttpSession, also available in the application session table, to invalidate the session, which forces WebSphere to clear it from the database. You can also customize the logoff operation to use this method to invalidate the session in all servers in the cluster when the user ends a session.

You must carefully handle the concurrency of several requests belonging to the same session when designing an application to run in this kind of environment.. Usually, you should avoid this situation. If there are strong requirements that force a solution to support concurrency for requests belonging to the same session, you must carefully configure the WebSphere products and ensure that both the toolkit infrastructure and the application process the requests successfully without having collisions, which usually occur during database updates.

In a non-affinity environment, the duplicate request handling feature (double-click support) of the HTML implementation of the multichannel interface is not supported. If you want to make use of this feature in a persistence environment, session affinity must be enabled (see Session affinity).

The diagram below depicts a possible scenario using Network Dispatcher to route the requests between two physical HTTP Servers for load-balancing. In each of the nodes, WebSphere takes control to distribute the load among the configured clones. To see the details of the clones, see the diagram in Request processing.

To support session persistence and session affinity, the toolkit server configuration file (btt.xml) has the parameters.

If you are using a persistence schema for sessions, you must enable cookies in the toolkit server configuration. Enabling or disabling session affinity has no effect unless session persistence is enabled.

The following XML shows cookies enabled: