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 Minutes: JDO TCK Conference Call Friday, Oct 16, 9 am PDT
Date Fri, 16 Oct 2009 17:21:29 GMT
Attendees: Michelle Caisse, Michael Bouschen, Craig Russell

Agenda:

1. Update DataNucleus dependencies in tck2 https://issues.apache.org/jira/browse/JDO-642

It looks like we should go with 2.0.0-m3-SNAPSHOT for now. This give  
us the ability to make changes to DataNucleus to resolve issues. AI  
Michael track down the dependencies and update the project.xml.

2. Query timeout test - need option to test for support? https://issues.apache.org/jira/browse/JDO-623

As a reminder, the original JIRA issue was opened by Andy in February:

> 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. I propose having the following
>
> 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.
>
> Add methods Query.setTimeout(int), Query.getTimeout() to allow  
> setting/retrieving the timeout interval on a per-query basis.
>
> Add method Query.cancel() to cancel any running query. If an  
> implementation doesn't support cancelling of queries then it should  
> throw a JDOUnsupportedOptionException. Any query execute() that is  
> cancelled will throw a QueryInterruptedException (extends  
> JDOUserException).


Subsequently, Andy wrote:

> You mean the datastore itself always supports a timeout?or do you  
> mean a JDO
> implementation can manage a timeout itself ? The former is clearly  
> not the
> case since there are a wide variety of datastores, some file based,  
> with APIs
> that don't provide such things as timeouts.

Low-function datastores (file systems, etc.) don't need a timeout  
because the query is executed by the JDO implementation itself. And  
the JDO implementation can add hooks to the execution processing so as  
to time out the function.

High-function datastores generally provide a user-specified timeout.  
Access to the underlying connection to the datastore is mediated by  
the JDO implementation, so the expectation is that the JDO  
implementation will pass the user's timeout request directly to the  
underlying connection.

> RDBMS datastores do allow a
> timeout to be set yet JDBC is so imprecisely defined that you get an
> SQLException and so have no simple way of knowing that it was a  
> timeout
> (without having to play around with arbitrary JDBC error numbers).

This is precisely why we want to define the timeout at the JDO user  
level and not require the user to play around with JDBC. There are  
many features in JDO that get translated into datastore-specific  
methods and this is just one more. I expect that for a specific  
datastore, a query timeout will have a specific SQL error code, even  
if not all datastores implement the same codes.

> PS, what is the definition of the timeout ? Is it the time taken to
> communicate with the datastore ?

The user is in control of activities inside the VM, and there's no  
need for a JDO-specific timeout for these. What we want to influence  
is what happens once the query leaves the JDO implementation. So the  
timeout would be on the JDBC statement.execute call.

> or is it the total time for the query
> execution (which may include compilation) ?

Since the user can compile the query, the timeout should just apply to  
the database processing and not include the preparation or post-query  
processing.

3. javax.jdo.Enhancer fails to pass full path name for the file  
arguments https://issues.apache.org/jira/browse/JDO-641

Looks like the patch program did not install the zero-byte test files.  
After manually touching the test files, the test now runs. AI Michelle  
test the tck to see if this allows the tck change to work and update  
the JIRA.

4. Add annotations for instance callbacks.  https://issues.apache.org/jira/browse/JDO-638

No news.

5. Other issues

  https://issues.apache.org/jira/browse/JDO-643 says avg should not  
return the type of the enclosed expression but should always return  
double. AI Michelle take a look at the SQL implementations to see what  
they do and then we can decide what make sense. This would be an  
incompatible change so we need to look at the implications.



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
View raw message