[
https://issues.apache.org/jira/browse/OPENJPA-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625436#action_12625436
]
Pinaki Poddar commented on OPENJPA-703:
---------------------------------------
It always looks promising from performance perspectives to cache stuff that
takes long time to compute. But caution must be exercised to cache query
results (as opposed to parsed query such as PreparedStatement). Because time of
execution is extremely significant for result of a query. Caching a result may
lead to erroneous behavior because a cached version of data collected at time
T1 may not reflect the actual result at T2 when T2 > T1.
As far as caching parsed query itself goes, as the experience with OPENJPA-407
shows, is a non-trivial undertaking because of the context of query execution.
To cache we need a key and we have made up a QueryKey. The content of the key
dictates what we consider as the context of execution. But care must be taken
to define the context. For example, as FetchPlan not being part of the query
key can lead to erroneous behavior as documented in [1]. Such caching also
limits or at least makes it more coupled to add more context information to a
query.
http://issues.apache.org/jira/browse/OPENJPA-671
> Cache ResultObjectProvider data to improve query performance
> ------------------------------------------------------------
>
> Key: OPENJPA-703
> URL: https://issues.apache.org/jira/browse/OPENJPA-703
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Ron Pressler
>
> Profiling indicated that JDBCStoreQuery.populateSelect consumes a significant
> amount of CPU, and is executed every time a query is run. While, in fact, the
> actual PreparedStatement is created and run only in QueryImpl.toResult. It
> seems like the returned ResultObjectProvider from JDBCStoreQuery.executeQuery
> can be at least partially cached, or even cached in its entirety (provided
> care is taken with the context parameters).
> It seems like such an improvement would significantly improve query
> performance.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
