Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4715A19F.4030108@comintel.com>
Date: Wed, 17 Oct 2007 01:46:07 -0400
From: Don Brady <dbrady@comintel.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: dev@openjpa.apache.org
Subject: Re: Question: Application of QueryCompilationCache for find() and
 lazy relationships?
References: <89c0c52c0710110859o30d723acocfe5aea142f059bd@mail.gmail.com>
 <7262f25e0710111001k3481d5a3jb87334cdd51f6502@mail.gmail.com>
 <89c0c52c0710160719t28e90cbft55965e16c4b7d425@mail.gmail.com>
 <7262f25e0710160818s6b5258fcj6b1f266a45967675@mail.gmail.com>
In-Reply-To: <7262f25e0710160818s6b5258fcj6b1f266a45967675@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Just to add a user note if not inappropriate, my company would really 
like to see this.

We are finding that our OpenJPA application runs slower than a pure JDBC 
application and it looks as if the re-generation of the dynamic SQL is a 
major factor....

By the way, on another note, I have never seen anything as robust as 
OpenJPA is proving to be - we have not run into a single bug or memory 
leak since we deployed our application to Production on WebSphere 6.1 
the better part of a year ago.  I expected at least the occasional 
issue, but no problems at all have transpired!

Don


Patrick Linskey wrote:
> Hi,
> 
> Yes, SQL caching will be a big win. Sadly, as you point out, there is
> no one clear spot to do the caching, and a number of things must be
> incorporated into the key for the cache. That said, it's definitely
> doable.
> 
> -Patrick
> 
> On 10/16/07, Kevin Sutter <kwsutter@gmail.com> wrote:
>> Patrick,
>> As I continued to look at this area, it really wasn't the lack of the Query
>> Compilation Cache that was causing the performance concerns (as I believe
>> you had already figured out).  But, rather, it's the constant re-generation
>> of the dynamic SQL that is causing the performance concerns.  Even when
>> dealing with named queries, the SQL is always generated from scratch when
>> performing the execute().
>>
>> I've started to look at possibly caching the generated SQL or at least
>> aspects of the SQL string, but so far, I have not found the "magic spots"
>> for any necessary caches.  The generation of the SQL seems to be tightly
>> bound with the processing of the query itself (setting parameters, setting
>> hints, setting max results, etc).  Anyway, I am still digging into this
>> during my spare time to see if I can help out with this performance
>> concern...
>>
>> Thanks,
>> Kevin
>>
>> On 10/11/07, Patrick Linskey <plinskey@gmail.com> wrote:
>>> The query compilation cache doesn't cache data that would be directly
>>> useful for those calls. However, I'm all for optimizing those
>>> pathways, and the query compilation cache could be a place to store
>>> whatever intermediate caches we are able to assemble.
>>>
>>> -Patrick
>>>
>>> On 10/11/07, Kevin Sutter <kwsutter@gmail.com> wrote:
>>>> Hi,
>>>> For those of you that are more verse with the QueryCompilationCache, I'm
>>>> wondering how difficult it would be to utilize this type of cache for
>>> the
>>>> em.find() operations as well as traversal of lazy relationships.  We're
>>>> finding that these operations are more prevalent in customer's
>>> applications
>>>> than the use of createQuery() and createNamedQuery() operations and it's
>>>> affecting our performance (especially as compared to our
>>> competitors).  So,
>>>> I am wondering whether anybody has put any thought in this space before
>>> I do
>>>> a deeper dive.  Any suggestions or thoughts?
>>>>
>>>> Thanks,
>>>> Kevin
>>>>
>>>
>>> --
>>> Patrick Linskey
>>> 202 669 5907
>>>
> 
>