> 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: http://n2.nabble.com/Re%3A-svn-commit%3A-r743396---in--openjpa-trunk%3A-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-ap-tp2310190p2311475.html Sent from the OpenJPA Developers mailing list archive at Nabble.com.
