Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <498C7EE0.6040402@spree.de>
Date: Fri, 06 Feb 2009 19:18:08 +0100
From: Michael Bouschen <mbo.tech@spree.de>
Organization: akquinet tech@spree GmbH
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: jdo-dev@db.apache.org
CC: jdo-experts-ext@Sun.COM
Subject: Re: Long running queries : timeout, and cancellation
References: <200902061000.02741.andy@datanucleus.org>
 <498C7A57.5060206@spree.de> <AA66B1C0-5A9C-4D88-93CA-00F389C91409@SUN.com>
In-Reply-To: <AA66B1C0-5A9C-4D88-93CA-00F389C91409@SUN.com>
Content-Type: multipart/alternative;
 boundary="------------000301010504040705040107"

--------------000301010504040705040107
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi Craig,
> I also think option 3 is the best way to go.
>
> I couldn't recall it during the meeting, but I looked again at the 
> JDBC API and found Statement.cancel() which matches the proposed 
> semantics, and isn't even a recent API.
>
> The JDBC expert group is working on a different proposal to add 
> abort() which is a much stronger semantic, essentially destroying the 
> Connection. This is probably not a good match to the semantics we're 
> talking about here.

thanks for the info!

So, since the new JDBC method abort has a different semantics, it might 
be confusing to call the JDO Query method abort. I withdraw my proposal 
and we should go for Query.cancel.

Regards Michael

>
> Craig
>
> On Feb 6, 2009, at 9:58 AM, Michael Bouschen wrote:
>
>> Hi Andy,
>>
>> I think this is a good idea and we should add this to the next release!
>>
>> I agree to go for option 3 and add a method to the Query API to abort 
>> query execution. BTW, maybe abort is a better method name for the 
>> method, what do you think?
>>
>> I'm wondering whether there are any implementation issues. AFAIK, 
>> there is no standard JDBC API to abort a a running JDBC query. So how 
>> about allowing the method to throw a JDOUnsupportedOptionException in 
>> case it cannot be implemented for the underlying database?
>>
>> Could you please file a "New Feature" JIRA for this?
>>
>> Regards Michael
>>
>>
>>> JDO doesn't have a mechanism to stop queries from overrunning. JPA2 now allows 
>>> a persistence property to allow timing them out, and most JDO implementations 
>>> have allowed this as an extension since JDO1. It would make sense for JDO 
>>> (2.3) to have the same or a variation. Some ideas
>>>
>>> Option1 :
>>> Simple PMF property "javax.jdo.option.queryTimeout" to specify the number of 
>>> millisecs (or secs) before any query is timed out. Throw a 
>>> QueryTimeoutException (extends JDOException) when the timeout happens
>>>
>>> Option2 :
>>> as Option1, plus setTimeout() on Query to define it on a per query basis.
>>>
>>> Option3 :
>>> as Option2, plus we add cancel() on Query so that users can cancel long 
>>> running queries programmatically, throwing a QueryInterruptedException 
>>> (extends JDOUserException). The cancel would apply to all currently running 
>>> invoked queries from that Query instance.
>>>
>>>
>>>
>>> I'd go for option 3 since it provides full control in one change and we won't 
>>> need to revisit the area later to add extra control. Comments ?
>>>
>>>   
>>
>>
>> -- 
>> *Michael Bouschen*
>> *Prokurist*
>>
>> akquinet tech@spree GmbH
>> B�lowstr. 66, D-10783 Berlin
>>
>> Fon:   +49 30 235 520-33
>> Fax:   +49 30 217 520-12
>> Email: michael.bouschen@akquinet.de
>> Url:    www.akquinet.de <http://www.akquinet.de>
>>
>> akquinet tech@spree GmbH, Berlin
>> Gesch�ftsf�hrung: Prof. Dr. Christian Roth, Martin Weber
>> Amtsgericht Berlin-Charlottenburg HRB 86780
>> USt.-Id. Nr.: DE 225 964 680
>
> Craig L Russell
>
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
>
> 408 276-5638 mailto:Craig.Russell@sun.com
>
> P.S. A good JDO? O, Gasp!
>
>


-- 
*Michael Bouschen*
*Prokurist*

akquinet tech@spree GmbH
B�lowstr. 66, D-10783 Berlin

Fon:   +49 30 235 520-33
Fax:   +49 30 217 520-12
Email: michael.bouschen@akquinet.de
Url:    www.akquinet.de <http://www.akquinet.de>

akquinet tech@spree GmbH, Berlin
Gesch�ftsf�hrung: Prof. Dr. Christian Roth, Martin Weber
Amtsgericht Berlin-Charlottenburg HRB 86780
USt.-Id. Nr.: DE 225 964 680

--------------000301010504040705040107--