openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pinaki Poddar (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-703) Cache ResultObjectProvider data to improve query performance
Date Mon, 25 Aug 2008 17:45:45 GMT

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


Mime
View raw message