openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <>
Subject Re: Possible performance concerns?
Date Fri, 03 Nov 2006 15:52:27 GMT
On 10/27/06, Abe White <> wrote:
> > Fair enough.  But, unless Kodo is replacing the JPQL parsing, I
> > don't see
> > how you can get around this problem.  I suppose it's possible that
> > other
> > performance improvements could negate the performance hit
> > associated with
> > the reflective class loading.  But, it would seem that if Kodo 4.1
> > is using
> > OpenJPA, then these same type of issues would exist there.
> Kodo caches compiled queries.

Is there a plugin point where we could add a compiled query cache? It seems
like something that would be nice to have in OpenJPA, even if it isn't as
robust as the one in Kodo.

Also, regarding a name->type cache, we already have that in OpenJPA
> with the MetaDataRepository.getMetaData(String alias, ...) method.  I
> don't know anything about our JPQL parsing, but I'm sure it's already
> using that method.  Maybe it tries to use both that method and then
> reflective loading if no alias exists?  Does it try to load anything
> other than the "from" clause members as classes?

I did a little playing around, in my non-exhaustive testing it seemed to
call classForName each time you accessed a field on an Entity.

"Select p.firstName from Person p where = 1" called
QueryImpl.classForName twice.
"Select p.firstName from Person p" called classForName once.

I really haven't looked into this enough to know whether I'm just being
dense, is there a way to cache the class so we don't have to look it up each

> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
-Michael Dick

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