Dmitry Yemanov wrote:

>"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?
>
>
>

The attachment id isn't required, just the token, which must be unique
database wide.

Here is a proposed implementation:

1. A request token is generated if requested by isc_dsql_sql_info.
2. The request takes out an exclusive lock on the request token with
a blocking ast. The lock data is the client's account id (if the
engine holds an exclusive lock on the database, this lock doesn't
need to be expressed to the lock manager).
3. When a "request cancel" is received on an attachment it loops
through local attachments and requests to find the request with
the given token. If found, it is flagged for cancellation.
4. The the request isn't local, the engine gets a null lock on the
given request token, reads the account id from the lock data, and
validates access permission. It then requests a shared lock on
the request token.
5. The target request gets a blocking AST indicating that is should
consider itself cancelled.

In the non-file shared case, everything is handled locally.

There is a little trickery required for general database unique request
tokens for classic mode that I suspect can be handled by lock data.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376