[
https://issues.apache.org/jira/browse/OPENJPA-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627237#action_12627237
]
Ron Pressler commented on OPENJPA-703:
--------------------------------------
Come to think of it, for queries there's yet a simpler solution. Don't cache
the generated SQL in a shared cache - simply return it along with the "compiled
query" in the Query object returned to the user. If the fetch plan changes -
discard the statement and regenerate it during the next execution. True, this
does not implement a true cache, but it will provide significant performance
improvements in the common case.
I just don't like seeing the SQL generation process taking over 30% of my
program's execution time when I simply execute the SAME QUERY OBJECT over and
over again.
I would have loved to fix this issue myself, I'm just not yet familiar enough
with the inner workings of OpenJPA. Getting there.
> 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.
