Two or more sessions can be connected simultaneously to the same (or different) databases. Each session can process two or more requests simultaneously as previously discussed for multi-request management.
Prior to considering a multi-session approach, an application programmer should determine whether multi-statement requests on a single session satisfy throughput and response time requirements. A multi-session application is much more complicated to implement, debug, and maintain. In addition, depending on the application, multi-session techniques can result in deadlocks and open timing windows that can leave the database in an inconsistent state. Nevertheless, CLIv2 provides facilities to assist implementation of multi-session applications.
- Wait for completion of a particular request on a particular session, just as it would if only one session existed,
- Wait for the completion of any of the active requests, or
- Wait for any combination of the previous two.
Waiting for completion of a particular request is the simplest from a programming standpoint, but it may result in more time spent waiting than is necessary because other requests might complete before the one being waited upon, and the application could be processing those responses.
Waiting for the completion of any request is more complex programming, but results in the minimum amount of time waiting because the application is never waiting when a response is available for processing.
How It Works
- Connect
- Initiate Request
- RunStartUp
- Initiate with Protocol-function
- Command
Using Tokens
An application can also supply a token for each request when it is initiated. That token is returned by the DBCHWAT routine when a request response arrives. An application can have requests pending on several sessions simultaneously.
One way for an application to wait is to call DBCHWAT. The wait ends when any request completes. The advantage of this first method is that it maximizes throughput by reducing session idle time. The application can handle the response and dispatch another request as soon as the previous request completes.
Using Fetch
An alternate way for an application to wait is to call DBCHCL for the Fetch function, using the Output-CLIv2-connection-number of an active session. The wait ends when the specified request completes. The problem with this method is that the application cannot know which of the active requests will complete first. The application calls DBCHWAT, which determines which requests are active and waits for any of them to complete. When a request completes, DBCHWAT returns to the caller the Output-CLIv2-connection-number and optional user-specified token associated with the completed request. The application can then handle the response, dispatch another request, and again call DBCHWAT.
| Language | Location of Sample on the Release Tape |
|---|---|
| IBM Assembler | EX2 |
| COBOL | CLI2MCB |
| PL/I | CLI2MPB |