[jira] Updated: (OPENJPA-703) Cache ResultObjectProvider data to improve query performance

["Pinaki Poddar (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OPENJPA-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pinaki Poddar updated OPENJPA-703:
----------------------------------

    Attachment: PreparedQueryCache.pdf

This document describes the main issues and how they have been addressed in designing Prepared Query Cache -- which bypasses normal pathway of JPQL query execution by reusing the target SQL and other internal constructs. 

One of the design goal is to minimize intrusion to current pathways. The outcome is that the only change a OpenJPA developer must keep in mind is 
while contributing to a SQLBuffer from the Query Expression Tree nodes is to distinguish between a user-supplied query parameter from an internally 
inserted parameter (such as Literal or Const). 

> 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
>            Assignee: Pinaki Poddar
>         Attachments: PreparedQueryCache.pdf
>
>
> 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.