17.10 - Multi-Thread 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
17.10
Release Date
October 2021
Content Type
Programming Reference
Publication ID
B035-2418-061K
Language
English (United States)
A thread, in the context of CLI, is an open request on a database session.

How It Works

Multi-threading involves having two or more requests open on a single session. The application program can intersperse calls to DBCHCL for the Initiate Request function and calls to DBCHCL for the Fetch function. In this way it can submit new requests while examining responses from older requests.

The application opens the request by calling DBCHCL for the Initiate Request function. The request is considered open until the application calls DBCHCL for the End Request function.

Two rules apply to multi-threading operations:
  • No more than one Teradata SQL request can be active at one time per session, with the following exception: an abort request and a disconnect request are accepted on a session that has some other request active.
  • No more than sixteen Teradata SQL requests on the database can be open at one time (per session).

Multi-thread management supports techniques functionally similar to multi-session techniques, but on a single session.

Identifying a Request

The application program may identify a request by its session number and request number, or by assigning it a token which is used with DBCHWAT and a request number. The request number is the input argument for subsequent Fetch, Rewind, and EndRequest operations against the request.

DBCHCL maintains response buffer context such as current position and amount of data in the buffer. Thus, the application can fetch the response data from any open request, initiate other requests, or both, as desired.

Example

An application might initiate a request that contains a SELECT statement to return several response rows. The application might fetch a response row, and initiate a request that contains an UPDATE for that row.

Another response row could then be fetched, and another UPDATE sent. The results of the UPDATE could be checked when desired. The application need only keep track of the request number.