Shreyas Kaushik wrote: > 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.
The timer expiring would just call cancel on the statment object, thus moving the problem of thread notification to the cancel method. That's why I've been saying along, implementing cancel is a prerequiste for setQueryTimeout. > 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). Not sure if this was a question, but I think cancel() does go deep into the engine, and is a non-trivial fix. I know Derby today does handle a Thread within Derby being interrupted, using Thread.interrupt(). If you looked at that code, I think it could be modified to handle cancel(). Of course, the actual behaviour of cancel needs to be resolved before you start implementing it. These are the questions that need to be answered (and probably more) to give an idea of what the behaviour would be. What happens if the Statement object isn't active What happens if the Statement object is closed Is the Statement object closed by a cancel? Does a cancel cause the transaction to be rolled back, or just the statement, or does it just stop execution and not rollback any changes made so far? Note that a PreparedStatement and CallableStatement inherit Statement behaviour so cancel needs to work on them. What are all the states that a Statement object could be in when cancel is called on it? Dan.
