Persistence schema for load-balancing and failover support
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:
▪ Support and integration with the WebSphere load-balancing, failover, and session affinity features
▪ Persistence of the context associated with the session, according to the standard WebSphere policy for session persistence schemas, using toolkit serializable contexts
▪ Persistence of the processors launched during the session, according to the standard WebSphere policy for session persistence schemas, using toolkit serializable contexts and other base Java serializable objects
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.
In UDTT, multichannel support for persistence includes the following main areas:
▪ The context associated with the session
▪ The information associated with the processors started during the life cycle of the session
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.
Request processing
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:
Session affinity
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.
Process with session affinity enabled
If it has been configured with session affinity enabled, the toolkit uses the following schema when it processes a request:
1 If there is an entry in the application session table (the one maintained in memory by the Context class and managed by the application) for the HttpSession, the session is still active so the toolkit does not re-instantiate the session context. Otherwise, the toolkit re-instantiates the context for the HttpSession, restoring the data from the database contents. The toolkit updates the application session table with the proper session information and chains the session context to the root context.
2 The toolkit processes the request. During the processing, the toolkit reactivates the required processors from the HttpSession, restoring the processor data from the database contents.
3 Once the toolkit completes processing the request, it releases the processors back to the HttpSession so that the processor data can be saved to the database when the toolkit returns control back to WebSphere. The entry for the current HttpSession in the application session table is maintained in memory.
4 The toolkit puts the session context back into the HttpSession.
5 The toolkit returns control back to WebSphere. WebSphere saves the objects that the toolkit put into the HttpSession during the processing of the request (that is, the session context and the active processors) into the database.
Process with session affinity disabled
If it has been configured with session affinity disabled, the toolkit uses the following schema when it processes a request:
1 The toolkit re-instantiates the session context for the HttpSession, restoring the data from the database contents. The toolkit updates the application session table with the proper session information and chains the context to the root context.
2 The toolkit processes the request. During the processing, the toolkit reactivates the required processors from the HttpSession, restoring the processor data from the database contents.
3 Once the toolkit completes processing the request, it releases the processors back to the HttpSession so that the processor data can be saved to the database when the toolkit returns control back to WebSphere.
4 The toolkit puts the session context back into the HttpSession.
5 The toolkit clears the entry for the current session from the application session table.
6 The toolkit returns control back to WebSphere. WebSphere saves the objects that the toolkit put into the HttpSession during the processing of the request (that is, the session context and the active processors) into the database.
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:
▪ preProcessRequest, which is responsible for restoring info to the application session table
▪ service, which stores the information in the HttpSession object once the request has been processed
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.
Configuration for session persistence and session affinity
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.
