15.10 - Multi-Session Management - Call-Level Interface Version 2

Teradata Call-Level Interface Version 2 Reference for Mainframe-Attached Systems

prodname
Call-Level Interface Version 2
vrm_release
15.10
category
Programming Reference
featnum
B035-2417-035K

Two or more sessions can be connected simultaneously to the same (or different) servers. 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.

Because each session can have an active request, an application can either:

  • 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

    Each concurrent request can be identified to CLIv2 by using both the ID of the session with which it is associated (that is, the value in Output Session Id from a call to DBCHCL for the Connect function) and its own ID (that is, the value in Output Request Id from a call to DBCHCL for these functions:

  • 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 session id 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 session identifier 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