db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Long running queries : timeout, and cancellation
Date Fri, 06 Feb 2009 18:05:12 GMT
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.

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
>
> 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!


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