> >>However, it is possible to send interruption request using the
> >>original socket. I even believe it can be done in the current SS
> TCP
> >>listener without mass modification. Current TCP listener
> >>implementation receives and dispatches packets asynchronously of
> >>other threads executing them. So it can happily receive
> interruption
> >>request and notify the worker thread to stop.
> >>The client side should use some per-socket synchronization to keep
> >>data separate and submit cancel requests from a different thread
> >>since the primary thread is blocked.
> >>
> >>
> > Not without redesigning the wire protocol, server code, and remote
> > interface and changing the layering within the server. It also
>
> Nothing has to be redesigned, really. In theory, there should appear
> new message type in remote protocol, but the existing one for
> isc_free_statement () could fit. Overall client interface change is
> indeed adding a new constant in ibase.h as Borland did. BTW, as far
> as I understand, IB6.5 still opens separate connection to cancel
> queries.
>
> > precludes extending the interruption mechanism to let a dba kill
> > selected requests.
>
> Interruption mechanism in the engine is the same
> (gds_cancel_operation) and it is operational for a few years,
> however, only for SuperServer. The absent part is the means of
> delivery of the cancel request from a client to server. Cancelling
> users' own queries is easy and can be done over a weekend.

Then why hasn't it been created yet?

Heck, the feature has been sponsored for once - someone had
made a time-estimation for it ...

But it all ended there.

With regards,

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com