db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg von Frantzius <joerg.von.frantz...@artnology.com>
Subject Re: query timeout in JDO
Date Fri, 11 Dec 2009 12:31:26 GMT
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 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!
>


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


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message