Two or more responses can be processed simultaneously for a session. After a request is initiated, no other request can be initiated for that session until the previous one completes. After a request completes, the entire response need not be processed before initiating another request. In this way, the application may process multiple responses in parallel.
The response being processed is identified by its request number, which is returned to the application when a request is initiated. CLIv2 maintains the last parcel processed for each response, so as appropriate, the application processes the next parcel until all are exhausted. Up to sixteen responses can be processed simultaneously.
Note that this facility is primarily a functional, not a performance, enhancement. It supports techniques functionally similar to multi‑session techniques, but on a single session.
Identifying a Request
An application identifies a request by its session number and request number. A request can also be identified by an assigned token that is used with DBCHWAT and a request number. 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. The request number is the input argument for subsequent Fetch, Rewind, and EndRequest operations against the request.
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.
No more than one Teradata SQL request can be active at one time per session.