Attendees: Michelle Caisse, Michael Bouschen, Craig Russell
Agenda: 1. Update DataNucleus dependencies in tck2 https://issues.apache.org/jira/browse/JDO-642It 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 followingSimple 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 APIsthat 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 anSQLException 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 issueshttps://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.russ...@sun.com P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
