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