At 09:08 AM 1/16/02 +0400, Dimitry Sibiryakov wrote:

>On 16 Jan 2002 at 0:47, Helen Borrie wrote:
>
>> OK, this group is NOT for support questions.
>
> Of course, the question was wrong. But subject (I think)
>is interesting even here.
> AFAIK isc_dsql_execute2() won't return until the query
>execution is complete and the first row of the result set
>is ready for fetch. So, we have to call something like
>isc_break_execute() from a different thread.
> What is more "right" - make programmers to use multi-
>thread architecture or add "asynchronous calls" to API?
>(When an isc_dsql_execute_nowait() returns immediatelly and
>calls a callback function after the result is ready. In
>this case an isc_wait() may be good too. Oracle uses this
>method.)
>
> 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:

1. Always establish a secondary connection.
2. Implement a mechanism that declares an intention
to use a secondary 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.

If I were designing the feature, which I'm not, I'd always set
up the secondary connection just in case. Might even be able
to share it with the event alerter mechanism. I would also
add the corresponding call to the SQL api.

Jim Starkey