db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shreyas Kaushik <Shreyas.Kaus...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
Date Thu, 10 Mar 2005 12:48:45 GMT
Please see inline.

~ Shreyas

Daniel John Debrunner wrote:

>Jeremy Boynes wrote:
>
>  
>
>>Daniel John Debrunner wrote:
>>    
>>
>
>  
>
>>>The timer task should just be notifying the thread that is executing the
>>>statement that it needs to be cancelled, not performing the cancel
>>>itself.
>>>
>>>      
>>>
>>There is also an implementation of a WorkManager in Geronimo that you
>>could be using; the timer task would hand the workload over to that for
>>processing.
>>    
>>
>
>So currently Derby requires that all work within the context of a
>connection is single threaded. That is, only a single thread can be
>active within the engine at a time for a single JDBC connection.
>
>So for query timeout the tricky case is when thread A is executing the
>statement within the engine and is taking a long time, either waiting
>for a lock, in a user function, doing processing without returning rows
>to the user (e.g. a table scan with an aggregate).
>
>In this case the timer thread needs to notify thread A that it need to
>abort its execution and return control to the applicaition, through an
>exception on the JDBC method, e.g. ps.executeQuery() or rs.next(). I
>
I investigated this approach by having a private boolean variable in the 
EmbedStatement
class and trying to set its value through a setter method. This setter 
method is called only
when the time out happens on the TimerTask. So, from this point I was 
wondering how
to transfer the control to the "thread A" to signal the statement to 
stop executing.

In addition to the above queries should this implementation of 
cancelling a Statement
involve going much below the current level where I am working.
 ( I was thinking along the lines of activation or may be much below 
this in the engine).

>The
>rollback must occur in the context of thread A, not another thread.
>Thus, I believe the WorkManager from Geronimo will not be suitable.
>
>[the engine correctly handles multiple threads each with their own
>connection, and it correctly handles multiple threads concurrently (not
>advised) or serially using a single connection. In the concurrent case
>using a single connection, each thread is blocked at the JDBC layer
>until the other thread completes its jdbc method call.]
>
>Dan.
>
>  
>

Mime
View raw message