openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pinaki Poddar <>
Subject Re: svn commit: r743396 - in /openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/conf/ openjpa-kernel/src/main/java/org/apache/openjpa/enhance/ openjpa-kernel/src/main/java/org/apache/openjpa/kernel/ openjpa-lib/src/main/java/org/apache/open...
Date Wed, 11 Feb 2009 21:20:29 GMT

> Also, SelectImpl is using it, even though I question the behavior -
The point of distinction between a lock timeout and query timeout is valid.
But that discussion requires a different scope as well as change in the way
current implementation interprets these values. This current issue/commit
does not change existing usage/interpretation/implementation of hint values,
it retains the same behavior but consolidates collection of different query
hints from different parts of the system to present a single point of entry
(or failure:).

> Isn't it being stored in FetchConfigurationImpl.ConfigurationState.Hints?
The FetchConfigurationImpl.ConfigurationState.Hints holds a generic
name-value map and hence *can* hold the query timeout value as well. But
then the internal usage needs to be modified as well.

> How does a FetchPlan relate to the Delegating*Statement classes?
As a carrier of execution context information - some of the context
parameters (e.g. getLockTimeout()) appear as concrete APIs while a generic
map (FetchConfigurationImpl.ConfigurationState.Hints) keeps other
possibilities open.

View this message in context:
Sent from the OpenJPA Developers mailing list archive at

View raw message