Dmitry Yemanov wrote:

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

That would make sense. There's no reason to generate the token, let
alone take out the lock, if nobody is going to reference it.

>- What do you mean by "client's account id"?
>
>

Good question. Once upon a time users had internal ids. If that's gone
away, more thought needs to be given to security considerations (see below).

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

Any interrupt mechanism requires a second socket to send interrupt
message (OOB data doesn't work on many/most/all TCP/IP
implementations). This leaves two alernatives. Either the remote
interface establishes a second (or third if events are active) socket to
enable interruptions, or we create a separate socket with a second
attachment to transmit the interruption. There are at least two
problems with the second socket model. First, many systems are already
socket bound, and sockets created on speculation makes things must
worse. Second, the work of creating and destroying the extra socket is
complete wasted in the normal case of no interrupt. Creating a second
attachment is certainly more expensive than a second socket, but it
happens infrequently. I don't think there is any question that it's
cheaper from a system perspective to create a second attachment when
required than to create a large number of unused secondary sockets.

Going back to the security question raised above, let's try a different
tack. Rather than trying to verify permissions, why don't we use an
unforgeable token like a guid? Then, if we see a valid token, we can
safely assume that it originated from the client wishing to snuff out
his request.

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

There is almost no cost when running non-file shared in Vulcan.

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

Good point. It doesn't. Time to get creative again. How about an
attachment specific generic interrupt token that kill anything that
happens to be running? Any other ideas? Anyone? Anyone?

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

I never liked lock data (you don't want to know why it was in the VMS
lock manager), but sometimes it's damn convenient.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376