"Jim Starkey" <jas@...> wrote:

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

The application would need some extra logic anyway. Let's consider the
statement token cancellation scenario. If the currently active API call
successfully returns earlier than the engine processes the statement cancel
request, the application need to freeze and avoid the next API call,
otherwise we'll have another long-running statement and the entire goal is
not achieved. So a subsequent statement won't be executed at all under
normal conditions. The same for the attachment token cancellation scenario -
the client simply won't start the next statement. The only difference is
that the engine will keep a cancellation flag active and the client will
need to rollback its cancellation request via an extra remote call to avoid
the next statement being cancelled. But we could make the engine to track
the attachment request list and make an entire cancellation request a no-op
if no active requests exist.


Dmitry