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 <[EMAIL PROTECTED]> 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 <[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 > > > -- Patrick Linskey 202 669 5907
