IBM WebSphere Multichannel Bank Transformation Toolkit, Version 7.1

Architectural considerations

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 previous diagram in Request processing.

Diagram showing a possible scenario using Network Dispatcher to route the requests between two physical HTTP Servers for load balancing



Feedback