openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ron Pressler (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-703) Cache ResultObjectProvider data to improve query performance
Date Sat, 30 Aug 2008 19:33:44 GMT

    [ 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.


Mime
View raw message