Overview: Using Dedicated Sessions
Host administrators assign logical units (LUs) (for 3270 & 5250 hosts) or dedicated terminal or station IDs (for UTS & T27 hosts) to specific users for auditing, resource management, and security purposes.
Using the following process, LUs or terminal or station IDs are associated with sessions from previously configured pools in the Runtime Service. This ensures that specific sessions are assigned to specific clients at run-time. For information about configuring pools for use with dedicated sessions, see Creating Session Pools for Dedicated Sessions.
- When a request comes in from a remote client to a Web server or other service provider, the Web server identifies the remote client and maps the client to an assigned LU or terminal or station ID.
- The Web server then sets the instance name on the task bean (ITask) or in the task file, (IConnectorAccess) to the LU or ID, and executes the task. To see an example of how to specify LUs in a client application, see Implementing LU Support, Example.
- When the request reaches the run-time engine, the LU or ID is passed to the Runtime Service along with the request for a session.
For 3270 and 5250 sessions, multiple sessions can use the same LU, although the number can be limited. This depends on how the LU pool on the host is configured.
For UTS and T27 sessions, if the terminal or station ID is not specified in the UTS or T27 configuration that is associated with the pool, it is still used. Only one session can use a given terminal ID or station ID.
- If the Runtime Service has a pooled session with the specified LU or ID, and, in the case of UTS and T27 sessions, the ID is not in use, the session is returned and the task runs.
- If no such sessions are pooled, the Runtime Service attempts to create one using the specified LU or ID. If the session is created successfully, the session is returned and the task runs.
- If the session cannot be created, or, for UTS and T27 sessions, if the ID is in use, the Runtime Service provides an exception and the Web server exception handler can either wait a few seconds and try again, (assuming the ID is just busy with another client), or fail the request and inform the client.
- When the task is complete, the session is returned to the pool or destroyed, depending on the pool configuration settings.