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--