Tom et al,

Below is a brief recollection of what's been already discussed.

Jim's correct in saying that your idea cannot be supported by the remote
interface. Perhaps, it could be achieved via OOB packets, but I doubt this
is a reliable solution on all platforms. Unless someone is ready to
implement an asynchronous remote protocol, I'm afraid we cannot agree on the
scheme that works in the embedded mode only.

If noone has any new clever ideas, then cancellation requests should go in a
separate attachment. This means that we cannot rely on object handles and
need some tokens that are unique across server processes (think about
classic). It sounds practical to generate such tokens upon request by the
isc_info call. A good question is how should we request cancellation using a
new attachment. An ugly (Jim would disagree) but simple solution would be to
pass the request opcode and the token as DPB items (similar to how the
shutdown request is implemented), so the new attachment would be just a
temporary service one. We could even encapsulate this stuff into a new
client-only API routine for simplicity. I'm sure there may be other
solutions as well.

But let's step back a bit. What's usually required is to cancel a running
statement, whatever it is. In other words, it's enough to know only
attachment handle/token and request this attachment to cancel everything
currently active. This gives you a bit less precision in control over the
cancellation process, but usually this is okay. It also makes sense from the
administration perspective, as an admin should have an ability to stop
activity in any arbitrary attachment (without knowing the details of the
running statements). Of course, we could support both attachment- and
statement-level cancellation, but so far I don't see the real benefits of
the latter.

An attachment-level cancellation has two practical advantages: (a) it's
already implemented (this is what gds_cancel_operation() does since IB 6.0,
although it's not exposed to the public API) and (b) we already have unique
attachment tokens (isc_info_attachment_id). However, we need to implement
the signalling logic for classic and I foresee some issues there.


Dmitry