openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: Question: Application of QueryCompilationCache for find() and lazy relationships?
Date Tue, 16 Oct 2007 14:19:42 GMT
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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message