Sub-sessions

Sub-sessions provide the ability to manage multiple or concurrent sessions under the same session between the client and server. This enables applications to isolate certain session data from other instances. For example, a session context holds the data and services that are exclusive to a workstation. Two bank tellers are sharing the same workstation. Each teller has their own sub-session. The sub-sessions are isolated from each other but they all have access to the information in the session context and higher in the context hierarchy. This allows the tellers to share the workstation. The first teller's environment (sub-session and context) remains untouched by anything in the second teller's environment. However, both environments can access information at the parent context level such as the workstation ID and password.

The following process describes how this example could be implemented. In this case, one teller's login has created a session in the application logic layer and associated the workstation context (wks1) associated with the session. The process also added a session entry into the application session table to establish a link between the session and the context instance.

To support switching between applications, the login process establishes a sub-session for each teller. The following diagram shows what happens when user1 logs in from a Java™ client.

Diagram showing multiple user sessions under the same workstation session

In the scenario, the following happens:

  1. The login view creates the sub-session request. The context contains data belonging to user1.
  2. The client sends the request to the application presentation layer. The request includes the session ID and sub-session ID.
  3. In the application presentation layer, the request handler calls the corresponding invoker for the creation of the sub-session business process. The invoker sends the request to the application logic layer.
  4. In the application logic layer, the business process instantiates the user1 sub-session CHA context and chains it to the workstation CHA context (as shown by the dotted line). The business process returns the sub-session CHA context ID to the invoker, which in turn calls the CSSessionHandler to create an entry for the user1 sub-session in the session table.
  5. The presentation handler sends the response to the client with the session ID and user1 sub-session ID.
  6. The client updates the client context hierarchy to maintain the user1 sub-session ID between requests. The management of the sub-session ID between requests is the responsibility of the application implementation.
  7. Any subsequent requests that contain the user1 sub-session ID causes the application logic layer to chain the business process CHA context to the user1 sub-session CHA context and not the session CHA context. The application must map the user1 sub-session ID to the client operation before executing the operation.