FIX: Query Cancellation May Fail If No Delay After Query (185965)

MORE INFORMATION

From an API standpoint, query cancellation is done through the ODBC calls SQLCancel() or SQLFreeStmt(), or the DB-Library call dbcancel().

From a user interface standpoint, query cancellation is done by certain user actions that trigger one of the above APIs. For example, pressing CTRL+C in the Isql.exe console screen while results are returning will cause dbcancel() to occur.

The problem only occurs if queries are canceled immediately after sending. For example if, after sending a query with SQLExecDirect(), the query is immediately canceled with SQLCancel(), the problem may happen, but very infrequently. It typically occurs with less than 0.1 percent frequency.

It is unlikely that the timing window can be reproduced by a human-driven cancellation. Rather the application must do this programmatically using the above APIs.

When discussing this area, the terms cancel and attention are often used interchangeably. Also note that ACK is short for acknowledgment when used in a network or client/server context.

The problem occurs frequently with multiple connections and symmetric multiprocessing (SMP) hardware, however it can be seen under a single connection, uniprocessor environment. The problem is very timing sensitive and happens more frequently with local (unnamed) pipes than it does with a local network named pipe.

Detailed Description

The following is a detailed description of the mechanism of the problem. The client (running on a local server) sends a query and immediately cancels. The cancel results in writefile() on client, followed almost immediately by readfile(), waiting for ACK. The server continues running the query, and does not ACK the client, which causes the client to wait. The duration of the wait is proportional to the query running time: the bigger the table, the longer the wait. After the query completes, the ACK is sent and the client drops off of the wait.