On 16 Jan 2002 at 10:12, Jim Starkey wrote:

> > BTW, how this feature is implemented in IB6.5?
>
> The original API contained a call isc_unwind_request to
> stop execution of a request, but the implementation was
> problematical over a network. The problem, of course,
> is that an implementation takes a second channel between
> client and server. Establishment of the connection, however,
> must be done before the call is made. So the choices are:

Second connection?! What for? Does server stop receiving
packets from the client while a statement is been executed?
I guessed that a "connection" thread is always ready to
talk with client and distributes accepted requests between
a pool of "execution" threads. Am I wrong?

> 1. Always establish a secondary connection.
> 2. Implement a mechanism that declares an intention
> to use a secondary connection.

3. Push another packet into a primary connection.

> One of important network supported by Interbase in the early
> days was DECnet, in which connections were very, very expensive
> to establish. With TCP/IP, however, connections are dirty
> cheap.

I don't know how other protocols work, but TCP/IP doesn't
require answer before the next packet can be sent. And
don't mind sending packets from different threads into one
socket while another thread is waiting for incoming
packets. At last, sending can be synchronised to prevent
two threads from sending simultaneously.

> If I were designing the feature, which I'm not, I'd always set
> up the secondary connection just in case.

If I were programming the feature, which I'm not, I'd
have written on the client side something like:

void isc_abort(HANDLE *stmt, *db)
{
{ preparing "abort packet" }
...
thread_safe_send(socket, packet);
}

and on the server side:

...
switch(Received_packet.p_operation)
...
op_abort:
{ find statement executor }
Send_signal_to_thread_about_abort(stmt_exector);
...
}

> Might even be able
> to share it with the event alerter mechanism. I would also
> add the corresponding call to the SQL api.

I was wondered very much, when had known that event
alerter mechanism required a second connection. But, I'm
sure that that was done because of limitations of an
ancient network.

SY, Dmitri Sibiriakov.