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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 >
