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

>
> 1. A request token is generated if requested by isc_dsql_sql_info.

Okay.

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

- I suppose the lock is created by isc_dsql_sql_info too?
- What do you mean by "client's account id"?

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

Fine.

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

I'm not sure that a regular user A from attachment 1 should be able to
cancel a request running under A's credentials in attachment 2.

> 5. The target request gets a blocking AST indicating that is should
> consider itself cancelled.

Fine. I only hope that the connectivity layer developers will never decide
to unconditionally get tokens for every compiled request.

The only serious issue I see in your proposal is that it doesn't support
isc_dsql_execute_immediate().

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

Yes, this is a bit tricky, but doable.


Dmitry