From dev-return-6481-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Wed Oct 17 13:09:52 2007 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 83287 invoked from network); 17 Oct 2007 13:09:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Oct 2007 13:09:52 -0000 Received: (qmail 76387 invoked by uid 500); 17 Oct 2007 13:09:40 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 76367 invoked by uid 500); 17 Oct 2007 13:09:40 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 76358 invoked by uid 99); 17 Oct 2007 13:09:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Oct 2007 06:09:39 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of kwsutter@gmail.com designates 209.85.146.180 as permitted sender) Received: from [209.85.146.180] (HELO wa-out-1112.google.com) (209.85.146.180) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Oct 2007 13:09:31 +0000 Received: by wa-out-1112.google.com with SMTP id m28so2949869wag for ; Wed, 17 Oct 2007 06:08:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=mBkJpSJSjVE5z0GfkbKSSeM74227GOz93laW7iUlgq8=; b=jDSdHT2+1gclEFcHWNUgqHbYcZoldlQ93Kppt6BHo/DpVMJMHftAkKmDRDnlKr7mTp9p9nuR7hW4M1LWpjcooJVSaFRznp0LmJoamCH+0fkiKFkoEVMSAiZN2grhcZPSJadZXAZWY/DjRjLThX9kwBiIKZdZiuasY83OnPyJIRk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ZyK9YJrSZa/6u3NFHdL98E3qxi33XfnhnS/nncB8Gfx4H0GB5q0HMUQglv0C6FJSeQ6R6bJyG2ycObVOPgJ/ds7RgMOof/2TwslJC4fWW3FjFjT1ZrZDtmfvWtYVwY0YT0eRMDkOpPd7A7xZHftjbuoSNg5RYLg3ng4x/+k1D2g= Received: by 10.114.168.1 with SMTP id q1mr9827181wae.1192626533774; Wed, 17 Oct 2007 06:08:53 -0700 (PDT) Received: by 10.114.75.15 with HTTP; Wed, 17 Oct 2007 06:08:53 -0700 (PDT) Message-ID: <89c0c52c0710170608l1c34c70brd10915b6c1ea60d4@mail.gmail.com> Date: Wed, 17 Oct 2007 08:08:53 -0500 From: "Kevin Sutter" To: dev@openjpa.apache.org Subject: Re: Question: Application of QueryCompilationCache for find() and lazy relationships? In-Reply-To: <4715A19F.4030108@comintel.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_45367_4602694.1192626533758" References: <89c0c52c0710110859o30d723acocfe5aea142f059bd@mail.gmail.com> <7262f25e0710111001k3481d5a3jb87334cdd51f6502@mail.gmail.com> <89c0c52c0710160719t28e90cbft55965e16c4b7d425@mail.gmail.com> <7262f25e0710160818s6b5258fcj6b1f266a45967675@mail.gmail.com> <4715A19F.4030108@comintel.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_45367_4602694.1192626533758 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/17/07, Don Brady wrote: > > 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.... Right. It's going to be tough to perform as well as pure JDBC, but it's a nice goal... :-) The flexibility of dynamic SQL and the abstraction from the individual database idiosyncrasies makes OpenJPA a viable alternative. I think we can improve the area of SQL generation with the proper caching. This is just a tricky area of the code... 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! Thank you for the testimonial! I know from our interactions on both this forum and the WebSphere forum that you have had your share of questions... :-) But, it's great to hear that your experience with both OpenJPA and WebSphere has been so positive. Thanks, Kevin 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 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 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 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 > >>> > > > > > > ------=_Part_45367_4602694.1192626533758--