Aborting SQL Statements

[Shreyas Kaushik <Sh...@Sun.COM>]

Hi all,

 Can anyone let me know whether Derby supports aborting SQL Statements? 
And also is anybody working
to provide support for setQueryTimeOut() and cancel() in 
java.sql.Statement interface.

thanks
Shreyas

Re: Aborting SQL Statements

[Shreyas Kaushik <Sh...@Sun.COM>]

My queries,

~ How to stop the execution of the current Query statement?
~ On which thread should the interrupt method be called ?
~ How to know the statement that is currently active ?

thanks
Shreyas

Daniel John Debrunner wrote:

>Satheesh Bandaram wrote:
>
>
>  
>
>>But I think Derby's client JDBC driver, currently the IBM Universal
>>driver, has some support. (I haven't tested it..) IBM recently announced
>>contributing a Derby Client to Apache. If this client code is accepted
>>and has the implementation for setQueryTimeOut() and cancel(), it might
>>be easy to adapt that code to Embed driver as well.
>>    
>>
>
>Cancel() is a requirement for setQueryTimeout(), as I think once the
>timeout has expired, setQueryTimeout() would just call cancel() or its
>underlying logic. Thus if you want to implement these features, you need
>to start with cancel.
>
>I don't think the cancel in a network client will help in any way in
>implementing cancel() in embedded. The cancel in embedded needs to know
>about how queries or statements are executed. A starting point for
>investigation would be to see how the engine handles Thread.interrupt().
>Currently if a thread is interrupted the session/connection is closed, a
>similar mechanism would be needed for cancel. And it might make sense to
>change it so that if the thread is interrupted only the active statement
>is cancelled, I know the connection closing surprised some Cloudscape
>customers.
>
>Dan.
>
>  
>

Re: Aborting SQL Statements

[Shreyas Kaushik <Sh...@Sun.COM>]

Hi all,
 
 Can the implementation of canel() for embedded mode be done by closing the
activation for that particular statement when the query times out?

thanks
Shreyas

Satheesh Bandaram wrote:

> Right... Cancel() is going to be the tricky one to implement.
>
> Satheesh
>
> Daniel John Debrunner wrote:
>
>>Satheesh Bandaram wrote:
>>
>>
>>  
>>
>>>But I think Derby's client JDBC driver, currently the IBM Universal
>>>driver, has some support. (I haven't tested it..) IBM recently announced
>>>contributing a Derby Client to Apache. If this client code is accepted
>>>and has the implementation for setQueryTimeOut() and cancel(), it might
>>>be easy to adapt that code to Embed driver as well.
>>>    
>>>
>>
>>Cancel() is a requirement for setQueryTimeout(), as I think once the
>>timeout has expired, setQueryTimeout() would just call cancel() or its
>>underlying logic. Thus if you want to implement these features, you need
>>to start with cancel.
>>
>>I don't think the cancel in a network client will help in any way in
>>implementing cancel() in embedded. The cancel in embedded needs to know
>>about how queries or statements are executed. A starting point for
>>investigation would be to see how the engine handles Thread.interrupt().
>>Currently if a thread is interrupted the session/connection is closed, a
>>similar mechanism would be needed for cancel. And it might make sense to
>>change it so that if the thread is interrupted only the active statement
>>is cancelled, I know the connection closing surprised some Cloudscape
>>customers.
>>
>>Dan.
>>
>>
>>
>>  
>>

Re: Aborting SQL Statements

[Daniel John Debrunner <dj...@debrunners.com>]

Satheesh Bandaram wrote:


> But I think Derby's client JDBC driver, currently the IBM Universal
> driver, has some support. (I haven't tested it..) IBM recently announced
> contributing a Derby Client to Apache. If this client code is accepted
> and has the implementation for setQueryTimeOut() and cancel(), it might
> be easy to adapt that code to Embed driver as well.

Cancel() is a requirement for setQueryTimeout(), as I think once the
timeout has expired, setQueryTimeout() would just call cancel() or its
underlying logic. Thus if you want to implement these features, you need
to start with cancel.

I don't think the cancel in a network client will help in any way in
implementing cancel() in embedded. The cancel in embedded needs to know
about how queries or statements are executed. A starting point for
investigation would be to see how the engine handles Thread.interrupt().
Currently if a thread is interrupted the session/connection is closed, a
similar mechanism would be needed for cancel. And it might make sense to
change it so that if the thread is interrupted only the active statement
is cancelled, I know the connection closing surprised some Cloudscape
customers.

Dan.