Multi-Session Management - Call-Level Interface Version 2

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

Product
Call-Level Interface Version 2
Release Number
15.10
Language
English (United States)
Last Update
2018-10-07
dita:id
B035-2418
lifecycle
previous
Product Category
Teradata Tools and Utilities

Multi‑Session Management

An application can achieve true parallel request processing by using more than one Teradata Database session. The application can then dispatch several requests simultaneously, one on each session.

How It Works

Each concurrent request can be identified to CLI by using 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 the Connect, Initiate Request, or Run Startup function).

Using Tokens

The application may also supply a token for each request when it is initiated. That token is returned by the DBCHWAT routine when a request’s response arrives.

An application may have requests pending on several sessions simultaneously. One way for the application program to wait is to call an asynchronous wait using DBCHWAT. The wait ends when any outstanding request completes.

Using Fetch

An alternate way for the application to wait is to call a synchronous wait using DBCHCL for the Fetch function, using the session id of an active session. The wait ends when the specified session completes.

Usage Notes

On the one hand, the problem with this method is that the application cannot know which of the active sessions will complete first. On the other hand, an asynchronous wait (calling DBCHWAT) maximizes throughput by reducing session idle time. The application can handle the response and dispatch another request as soon as the session completes.

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.

Windows and Linux support a maximum of 1024 sessions (for a single process). All other UNIX‑based operating systems set the session limit based upon the maximum number of file descriptors returned from the ulimit UNIX command.

Considering Alternative Approaches

Prior to considering a multi‑session approach, the 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. But CLI provides facilities to assist implementation of multi‑session applications.