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 Re: query timeout in JDO
Date Thu, 03 Dec 2009 23:41:33 GMT
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 tech@spree GmbH
> Bülowstr. 66, D-10783 Berlin
>
> Fon:   +49 30 235 520-33
> Fax:   +49 30 217 520-12
> Email: michael.bouschen@akquinet.de
> Url:    www.akquinet.de <http://www.akquinet.de>
>
> akquinet tech@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 tech@spree GmbH
> Bülowstr. 66, D-10783 Berlin
>
> Fon:   +49 30 235 520-33
> Fax:   +49 30 217 520-12
> Email: michael.bouschen@akquinet.de
> Url:    www.akquinet.de <http://www.akquinet.de>
>
> akquinet tech@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 tech@spree GmbH
> Bülowstr. 66, D-10783 Berlin
>
> Fon:   +49 30 235 520-33
> Fax:   +49 30 217 520-12
> Email: michael.bouschen@akquinet.de
> Url:    www.akquinet.de <http://www.akquinet.de>
>
> akquinet tech@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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message