On Fri, Oct 16, 2009 at 7:21 PM, Craig L Russell <craig.russ...@sun.com>wrote:
> 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. > > Filesystem Datastores need timeout because: a) Connection: You might need take an exclusive lock in the file b) Operation: it might take too long to perform the operation because of the amount of data to process 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. > I disagree twice. 1) You suggest the user should handle the timeout differently per database, sometimes set a timeout on the JDO interface, and sometimes create a timer on the JVM level. This is not a transparent API anymore. 2) You take the responsibility from the JDO implementation to handle end2end issues, instead you delegate the responsibility to the driver, if any. You can delegate the responsability to a driver, but JDO is accountable for it and must ensure the timeout given by the user is respected. A concrete example of a driver bug handling timeouts: sometimes Oracle DB sends a RESET to the driver, but somehow it's ignored since the data is being transmitted and the RESET just came in between, the driver simple waits for more data indefinitely. This bug causes threads to wait and eventually you get errors such as outofmemory. > 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. > > I dont agree. The user sets a timeout on the total execution of the operation, and not only on part of it. For example DataNucleus can compile and evaluate queries in memory, so it never leaves the JDO implementation. In my opinion we should have two timeout settings: connection timeout and execution timeout. Execution timeout includes connection timeout. To me it's also clear that these timeouts should be applicable to all JDO persistence operations and not only to the query. However, you might want to mirror JPA functionality, but it's too RDBMS minded. Erik
