IBM WebSphere Multichannel Bank Transformation Toolkit, Version 7.1

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.


Feedback