db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@gmail.com>
Subject Re: Looking at DERBY-3908 (Add a mechanism for cancelling runaway transactions)
Date Thu, 23 Jun 2016 01:24:59 GMT
On 6/22/16 6:05 PM, Bryan Pendleton wrote:
>> https://issues.apache.org/jira/browse/DERBY-3908
>>
>> in network mode... seems to require that the DRDAConnThread be able 
>> to receive a message from the network
>> client even while it is waiting for a statement to executed and the 
>> result transported back to the client.
>
> Hi Brett,
>
> Ouch, I agree, this seems like a real challenge.
>
> Even if the DRDAConnThread could be persuaded to do this,
> I'm not sure there wouldn't be other complexities. For
> instance, what if there are already some other messages "waiting in
> the network" already?
>
> Would it help to open a separate network connection instead?
>
> That separate connection would then have to be able to indicate,
> reliable, *which* connection it wanted to cancel, and then the
> server, upon receiving that message, would have to hunt down that
> connection and call cancel on it.
>
> thanks,
>
> bryan
>
>
>
I think that some such implementation is how IBM's DRDA client drivers 
end up implementing Statement.cancel(). An out-of-band connection is 
created in order to call a system procedure which looks up the 
server-side session and cancels the statement. See 
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM+i+Technology+Updates/page/QSYS2.FIND_AND_CANCEL_QSQSRVR_SQL+and+QSYS2.CANCEL_SQL+procedures

Hope this helps,
-Rick

Mime
View raw message