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
--
View this message in context: http://www.nabble.com/Benefit-of-%40NamedQuery-tp16653037p16678006.html
Sent from the java.net - glassfish persistence mailing list archive at Nabble.com.