"Dmitry Yemanov" <dimitr@...> wrote:

>
> > 1. isc_statement_info makes a available a request "token"
>
> How are tokens generated?

To explain my thoughts better. Is this token global or attachment-wide? How
are you going to implement this in the classic mode?

I'd suppose that a token consists of attachment_id and uniquely generated
(incremented) id. Every attachment object contains a mapping between ids and
request handles (as it's done in the Y-valve). After receiving the cancel
command via API, the engine sends a signal containing this value. All
attachments validate the received attachment_id and the one who recognizes
itself looks up in his map and cancel this request. The problem here is that
the lock data is a single long whilst the proposal requires two longs.

Do you have other ideas?


Dmitry