Dmitry Yemanov wrote:

>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.
>
>

A problem with statement cancellation by attachment token is the
potential for a deadly race condition where the offending request
completed normally before cancellation was processed and the application
started a subsequent statement that gets inadvertently killed.

Consider, for example, an LDAP server. It uses a single attachment and
a thread per request. To kill one bad statement, you have to kill all
running statements, and maybe the next one, too.

Perhaps we need a more general cancel call, something like

fb_cancel (StatusVector, CancelType, Token)

where CancelType could be one of { Statement, AllStatements, Attachment }.