Hi Craig, I also find your proposal very good. This all makes more sense now.
Regards, Jörg On 12/04/2009 12:41 AM, Craig L Russell wrote: > Hi Michael, > > Good summary. > > The original request for this feature was to allow queries that were > either stuck (possible deadlock) or running away (query too complex > for the server to complete timely). > > Then, Jörg added a request for updates to time out if they were stuck. > > And others wanted to know whether the timeout applied to memory > operations or just database operations. > > I'd like to propose something completely different that attempts to > resolve all of the above issues. > > Define two new properties and associated apis: > DatastoreReadTimeoutMillis and DatastoreWriteTimeoutMillis. Get rid of > the QueryTimeoutMillis property. > > DatastoreReadTimeoutMillis applies to all operations on the datastore > that are associated with reading data, including getObjectById, > queries, refresh, navigation, and lazy loading of fields or properties. > > DatastoreWriteTimeoutMillis applies to all operations on the datastore > that are associated with writing data, including flush, commit, delete > by query. > > If multiple datastore operations are involved in satisfying a user > request, the timeout applies individually to each of them. > > The rules for specifying the timeout are the same as in the original > proposal: if specified on a query, the timeout applies only to that > query, with the default coming from the PM. If the operation is > related to a PM operation, the timeout comes from the PM api, with the > default coming from the PMF. > > Whether there is a timeout is determined by the optional features > property. I don't know of a datastore that supports read and write > timeouts separately, so the feature can simply be called > DatastoreTimeout and it either is supported or not. > > Craig > > On Nov 17, 2009, at 12:05 AM, Michael Bouschen wrote: > >> Hi, >> >> the current spec allows specifying a query timeout on a Query, a PM >> or a PMF. The PM defines the default for all Query instances of the >> PM and the PMF defines the default value for all PMs of that PMF. >> However, there are still three open issue in the query timeout area: >> >> (1) query timeout as an optional feature >> I propose to add query timeout as an optional feature. This means the >> collection returned by the PMF method supportedOptions includes the >> string "javax.jdo.option.QueryTimeout", if the JDO implementation and >> the datastore bound to the PMF supports query timeout. This would be >> a change in chapter 11.6 "Optional Feature Support" of the spec. >> >> (2) Scope of the query timeout value >> I propose that a query timeout value set for a PM applies to all >> "datastore query" operations issued by the PM. This includes >> relationship navigation, findByObjectId and lasy loading of collections. >> But how about modifying operations such as update, delete and insert? >> Does it make sense to apply the PM's query timeout for these >> operationsas well? I think this makes sense, but it might be less >> obvious, because these operations are part of the transaction commit. >> See also Jörg's recent email with subject "update timeout". This >> would be a change in chapter 12 PersistenceManager. Today chapter >> 12.6.3 "Query factory interface" specifies method setQueryTimeout. If >> we broaden the scope of a query timeout set on a PM, it might make >> sense to specify this in its own section, e.g. 12.6.9 "Query Timeout". >> >> (3) Definition of query timeout: datastore operation or JDO method? >> Does the query timeout apply to the underlying datastore operation or >> does it define the maximum execution time of the JDO method such as >> Query.execute? >> I propose the former, meaning use the query timeout value for the >> datastore operation. Otherwise, the JDO implementation would need to >> calculate the timeout for the datastore operation and need o guess >> the time needed to post-process the query result. If the datastore >> has the JDBC standard second resolution, and there is less than 1000 >> millis left in the timeout, what should be the timeout set on the >> datastore query statement? >> >> What do you think? >> >> Regards Michael >> -- >> *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: [email protected] >> Url: www.akquinet.de <http://www.akquinet.de> >> >> akquinet t...@spree GmbH, Berlin >> Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth >> Amtsgericht Berlin-Charlottenburg HRB 86780 B >> USt.-Id. Nr.: DE 225 964 680 >> >> -- >> *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: [email protected] >> Url: www.akquinet.de <http://www.akquinet.de> >> >> akquinet t...@spree GmbH, Berlin >> Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth >> Amtsgericht Berlin-Charlottenburg HRB 86780 B >> USt.-Id. Nr.: DE 225 964 680 >> >> -- >> *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: [email protected] >> Url: www.akquinet.de <http://www.akquinet.de> >> >> akquinet t...@spree GmbH, Berlin >> Geschäftsführung: Martin Weber, Prof. Dr. Christian Roth >> Amtsgericht Berlin-Charlottenburg HRB 86780 B >> USt.-Id. Nr.: DE 225 964 680 > > Craig L Russell > Architect, Sun Java Enterprise System http://db.apache.org/jdo > 408 276-5638 mailto:[email protected] > P.S. A good JDO? O, Gasp! > -- ____________________________________________________________________ artnology GmbH - Milastraße 4 - 10437 Berlin - Germany Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. DE 217652550
