> "Jim Starkey" <jas@...> wrote:
> >
> > 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?
>
> You will be laughing, but I was going to suggest exactly this ;-)
>
> 1) It doesn't require multiple tokens/locks at all
> 2) It does what users want, interrupting the blocked API call
> 3) An AST could be added to the already existing att_id_lock that could
> handle this task
> 4) The internal infrastructure is in place for about 5 years (it terminates
> an attachment after its endpoint dies in SS builds)
>
> All user need is to retrieve the attachment_id via isc_database_info() and
> pass it to the engine which then signals the lock.

May be transaction_id is better than attachment_id ?

And how about possible vulnerability when some bad boy will call isc_cancel_xxx
for all numbers from 1 to 1000000 ? I think - only i (and possible SYSDBA) can
cancel my running request.

Regards,
Vlad

PS BTW, if we'll have ability to cancel running request - we can implement
timeouts (attacment\transaction\request level) directly in client library