Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.

[Shreyas Kaushik]

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.