Tom Cole wrote:

>In our use of Vulcan as an embedded database, we need to be able to offer our users the ability to cancel long-running operations. For us, the logical unit of work to cancel is a statement, since all the heavy-lifting is done by DSQL. As such, we have implemented the following in our instance of Vulcan, and I'm posting this to ask if it is generally useful enough to push to the open source code base.
>
>Here's the entry definition as implemented in why/entrypoints.cpp:
>
>
>ISC_STATUS isc_dsql_cancel_statement( ISC_STATUS* userStatus,
> DsqlHandle * dsqlHandle,
> USHORT * flags );
>
>
>Where
>
> userStatus Standard status vector mechanism
> dsqlHandle A handle to a previously allocated statement
> flags New flags setting. Previous flags returned.
>
>This implementation assumes that a thread in the server process makes the determination that a cancel is required (presumably responding to a client request, or perhaps an administrative function, etc.) and invokes the cancel function to request that the statement be aborted. This requires that the statement handle be known to the canceling thread, even though it is possible that the statement was created and is being used by another thread. In fact, that's the only really interesting case for the embedded server, I think. In our case, a "watcher" thread handles administrative requests for the server, including handling cancel requests.
>
>
>

Tom, I don't think this is the way it should be done. I would be much
happier if a statement exported a token that could be used for a
subsequent cancel operation (token are never reused). The token
solution plays nicely with virtual system status tables, is free of race
conditions, and doesn't suffer the complications of handle reuse. I
don't think your solution generalizes very well, and we certainly don't
need two parallel mechanisms that do the same thing. It also doesn't
work across the remote interface, which is a huge problem. The token
solution can be made to work across independent attachments, and
consequently works for remote access as well as embedded use.

Stepping back from the particularly, there's a more important issue of
project management. The time to propose functionality and prospective
solutions is *before* you start coding, not after. The question of
statement cancellation has been discussed at length with a fairly broad
acceptance of the token solution.