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 t...@spree GmbH
Bülowstr. 66, D-10783 Berlin
Fon: +49 30 235 520-33
Fax: +49 30 217 520-12
Email: michael.bousc...@akquinet.de
Url: www.akquinet.de <http://www.akquinet.de>
akquinet t...@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.russ...@sun.com
P.S. A good JDO? O, Gasp!
--
*Michael Bouschen*
*Prokurist*
akquinet t...@spree GmbH
Bülowstr. 66, D-10783 Berlin
Fon: +49 30 235 520-33
Fax: +49 30 217 520-12
Email: michael.bousc...@akquinet.de
Url: www.akquinet.de <http://www.akquinet.de>
akquinet t...@spree GmbH, Berlin
Geschäftsführung: Prof. Dr. Christian Roth, Martin Weber
Amtsgericht Berlin-Charlottenburg HRB 86780
USt.-Id. Nr.: DE 225 964 680
