You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Michael Bouschen <mb...@spree.de> on 2009/11/17 09:05:24 UTC
query timeout in JDO
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
Re: query timeout in JDO
Posted by Joerg von Frantzius <jo...@artnology.com>.
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
Re: query timeout in JDO
Posted by Michael Bouschen <mb...@spree.de>.
Hi Craig,
I like the proposal. It solves the issue of having different timeout
values for read and write operation and the wording makes clear that the
scope of the timeout value is the datastore operation.
About the exception thrown in case of a timeout. I agree with what is
written in the minutes of the JDO TCK conference call: it is ok to throw
a JDODatastoreException, no need for a specific exception.
Regards Michael
> 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!
>
--
*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
Re: query timeout in JDO
Posted by Craig L Russell <Cr...@Sun.COM>.
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!
Re: query timeout in JDO
Posted by CE...@versant.com.
Hi !
Michael Bouschen <mb...@spree.de> wrote on 17.11.2009 09:05:24:
> query timeout in JDO
>
> 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.
Sounds fine as there might exists datastores which doesn't support these
feature.
> (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".
The "Query Timeout" shall be an option only for the JDO queries themself.
Keep in mind that the idea of JDO was to support any kind of datastore,
which means there exists implementations which don't use any kind of
datastore queries for operations like relationship navigation,
findByObjectId and lasy loading of collections.
> (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?
>From the JDO idea it should be on the operation of the
Query.execute(), but from a Vendor persective i would suggest that
we allow both and it shouldn't be gurantied that this value is exact,
as the underlying datastore might have some kind of tolerance for the
timeout
or has different resolution for there timer.
cheers
Christian
---
Christian Ernst
Software Engineer
Tel: +49-40-60990 338
Fax: +49-40-60990 113
EMail: cernst@versant.com
Versant GmbH
Wiesenkamp 22b
22359 Hamburg
Germany
Think Outside the Grid!
http://www.versant.com
Versant GmbH is incorporated in Germany.
Company registration number: HRB 54723, Amtsgericht Hamburg.
Registered Office: Wiesenkamp 22b, 22359 Hamburg, Germany.
Geschäftsführer: Jochen Witte
Re: query timeout in JDO
Posted by Joerg von Frantzius <jo...@artnology.com>.
Hi,
I somehow got the feeling that having a single property for both query
and and update timeouts will create confusion, if I got Michael right here.
Imagine somebody wants to set an update timeout, but doesn't want to
constrain the duration of queries (or have a higher timeout for
queries). Now if he sets the update timeout on the PM level, then he'd
have to unset the timeout for each and every query issued. That's
assuming that the timeout on the PM level will apply to all Query
objects created by the PM.
I'd propose to have distinct properties for query and update timeouts.
The RI has distinct methods for creating Statement objects for queries
and updates already, so it shouldn't be hard to implement.
Regards,
Jörg
On 11/17/2009 09: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
--
____________________________________________________________________
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