James,
thank you very much for that detailed explanation. Now I see clear. My
test (like virtually any micro benchmark) was not good enough. I will
follow your tips to do more (and better) performance measuring when the
application is finished. :-)
You talked about the possibility of modifying the named query? What do
you mean with "modifying"?
Thanks
Markus
James Sutherland schrieb:
> Named queries are parsed the first time they are executed, so you should get
> any parsing error on the first execution. They do avoid the execution cost
> when compared to dynamic queries, so should have a performance advantage.
> In general depending on the query and the database the JPQL parse cost may
> be a very small part of the total query execution, so avoiding the cost may
> not be that noticeable if you measure the entire cost including the database
> access.
>
> However note that the data access is in the database, and JPQL parsing is in
> Java, so in a multi-threaded Java server application only the Java portion
> will effect the load of your application server machine, and only the
> database portion will affect the load of your database machine. So
> depending which is your applications bottleneck, only one will be relevant.
>
> What does you test do exactly? Ensure that you execute the named query more
> than once, otherwise you are parsing the same as a dynamic query. Also
> measure the raw database cost, to see if the JPQL parsing adds measurable
> overhead. It may also be that you are some how modifying the named query
> after you create it such that it needs to be re-parsed.
>
>
>
> Markus KARG-2 wrote:
>
>> Dear Persistence Team,
>>
>> thank you for providing TopLink Essentials. It is a great product that
>> improved our productivity by far. :-)
>>
>> Today I am curious about @NamedQuery implementation in TopLink Essentials.
>>
>> According to the EJB 3.0 Persistence Spec, using @NamedQuery is
>> beneficial since (a) the QL syntax can be checked at compile time and
>> (b) the QL statement can be compiled and prepared at bean instantiation
>> what should result in higher performance.
>>
>> Well, in theory this sounds great, by my question is: Is that really
>> true for TopLink Essentials?
>>
>> I have done a small benchmark and actually the result was annoying. The
>> veryfier did not notice that I had a typo in my @NamedQuery syntax so
>> (a) is not working properly (maybe a bug?) and I did not find any
>> performance benefits compared to a non-named query created on the fly
>> from a Java string at runtime, so (b) is not really measurable.
>>
>> So what is the official statement of the persistence team on this topic?
>> Was my benchmark done in an unfair way, or is something planned to get
>> improved here in the future? What kind of prophilactic optimization is
>> TopLink doing on @NamedQuery and why is the verifier not telling about
>> my typo?
>>
>> Thanks a lot! :-)
>> Markus
>>
>>
>>
>
>
> -----
> ---
> http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
> http://www.eclipse.org/eclipselink/
> EclipseLink , http://www.oracle.com/technology/products/ias/toplink/
> TopLink
> Wiki: http://wiki.eclipse.org/EclipseLink EclipseLink ,
> http://wiki.oracle.com/page/TopLink TopLink
> Forums: http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
> http://www.nabble.com/EclipseLink-f26430.html EclipseLink
> Book: http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
>
--
http://www.xing.com/go/invita/58469