db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oyvind.Bakk...@Sun.COM
Subject Re: Implementing Statement.cancel()
Date Fri, 03 Jun 2005 07:56:29 GMT
Daniel John Debrunner wrote:
> Oyvind.Bakksjo@sun.com wrote:
>>Daniel John Debrunner wrote:
>>>I'll look into how I think you should track down the StatementContext.
>>Hi Dan,
>>have you had any time to look into this?
> Not a lot :-(

So I assumed, so I started digging deeper into it myself. I wrongfully 
assumed that a statement execution had a context object for its 
lifetime. Once I found out that the StatementContext object is assigned 
only when the statement is actively executing (setInUse/clearInUse is 
called, for instance, for each fetch from the ResultSet), I realized 
that there might not *be* an assigned StatementContext object when a 
thread calls cancel(). Therefore, I'll have to come up with a different 
solution for the cancel method.

On the other hand, I now have a working implementation of 
setQueryTimeout (which is actually what the DERBY-31 JIRA issue is 
requesting). cancel() is not a prerequisite for setQueryTimeout(). 
Statement execution propagates the timeout value down to the point where 
a StatementContext object is assigned (with setInUse), and a TimerTask 
(which, on timeout, sets a cancellation flag in the StatementContext 
object) is scheduled on a system-wide Timer. Hence, there'll be one more 
thread in the JVM per loaded Derby system (not per database). On 
clearInUse(), the TimerTask is cancelled.

I'm in the process of polishing a patch and writing functional tests for 

> I've been thinking about it and there are a couple of issues:
> 1) StatementContexts are created dynamically for the current running
> statement
> 2) Derby does not keep references to application JDBC objects below the
> JDBC layer. This is to ensure when any JDBC object (e.g. Statement)
> moves out of scope for the application, it will be garbage collected and
> lead to its closure.
> I wonder if from a StatementContext you can determine the activation
> because that would provide the link to the Statement.

Maybe that will be needed for implementing cancel(). I'll look into it 
when I've finished the current patch for setQueryTimeout().

Øyvind Bakksjø
Sun Microsystems, Web Services, Database Technology Group
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43419 / +47 73842119, Fax: +47 73842101

View raw message