Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Message-ID: <604960895.1234906259565.JavaMail.jira@brutus>
Date: Tue, 17 Feb 2009 13:30:59 -0800 (PST)
From: "Pinaki Poddar (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Subject: [jira] Resolved: (OPENJPA-703) Cache ResultObjectProvider data to
 improve query performance
In-Reply-To: <1464774417.1219684184194.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Pinaki Poddar resolved OPENJPA-703.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: 2.0.0-M1

> 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
>             Fix For: 2.0.0-M1
>
>         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.