Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Date: Mon, 14 Mar 2005 15:20:36 +0530
From: Shreyas Kaushik <Shreyas.Kaushik@Sun.COM>
Subject: Re: [jira] Updated: (DERBY-31) Statement.setQueryTimeout() support.
In-reply-to: <42323CB2.3000303@debrunners.com>
To: Derby Development <derby-dev@db.apache.org>
Message-id: <42355E6C.5000306@Sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla Thunderbird 1.0 (X11/20041208)
References: <62083428.1109222929604.JavaMail.jira@ajax.apache.org>
 <4220B84D.70304@debrunners.com> <422C0B22.3050808@sun.com>
 <422E0C60.8050108@debrunners.com> <422E11C1.7000504@apache.org>
 <422F36CE.60002@debrunners.com> <4230422D.40600@Sun.com>
 <42323CB2.3000303@debrunners.com>

Please see inline.

~ Shreyas

Daniel John Debrunner wrote:

>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().
>  
>
Interrupting a Thread in Derby causes the connection also to close, right?
Was this implementation by design?

>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?
>  
>
We should get things going here. If developers/users on the alias reply 
as to what exactly
is their understanding of cancel and what they need out of it. You are 
right I can start to
implement only after we have arrived at some maeningful opinion on this.

>Dan.
>
>  
>