db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Bouschen <mbo.t...@spree.de>
Subject Re: Long running queries : timeout, and cancellation
Date Fri, 06 Feb 2009 18:18:08 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message