The consumer should be able to cancel an active reader via MySqlCommand.Cancel() or the CancellationToken passed to ExecuteReaderAsync etc.
This probably needs to be implemented via KILL QUERY which may require a separate connection. It may be helpful to implement connection pooling #2 first and keep a spare connection around to issue this command.
The text was updated successfully, but these errors were encountered:
KILL QUERY on a second connection won't necessarily work in an environment of load-balanced secondaries; the second connection might be to a different physical server, which can't cancel the query running on the first server.
Is there any way the query can be canceled using the connection that's already open?
My assumption is that the consumer would expect the active command to be cancelled (cooperatively by the database) and that the connection would remain usable afterwards. Thus, we cannot implement cancellation by passing the CancellationToken down to the Socket methods and close the socket; it has to be handled at a higher level by executing KILL QUERY on a separate thread. (This will cause MySQL to return an error packet, which will need to be turned into a MySqlException or an OperationCanceledException depending on the mechanism of cancellation: DbCommand.Cancel or cancelling a CancellationToken.)
More specifically, the methods that expose cancellation are:
Handling the cancellation of a CancellationToken and calling DbCommand.Cancel (from another thread) can be implemented in a common fashion. (It may be possible to do something like (pseudocode) cancellationToken.Register(command.Cancel).)