Named Queries
First and foremost, we recommend named queries whenever possible. Persistence providers
will often take steps to precompile JPQL named queries to SQL as part of the deployment or initialization
phase of an application. This avoids the overhead of continuously parsing JPQL and
generating SQL. Even with a cache for converted queries, dynamic query definition will always
be less efficient than using named queries.
Named queries also enforce the best practice of using query parameters. Query parameters
help to keep the number of distinct SQL strings parsed by the database to a minimum.
Since databases typically keep a cache of SQL statements on hand for frequently accessed queries,
this is an essential part of ensuring peak database performance.
As we discussed in the Dynamic Query Definition section, query parameters also help to
avoid security issues caused by concatenating values into query strings. For applications
exposed to the web, security has to be a concern at every level of an application. You can either
spend a lot of effort trying to validate input parameters, or you can use query parameters and
let the database do the work for you.
When naming queries, decide on a naming strategy early in the application development
cycle with the understanding that the query namespace is global for each persistence unit. Collisions
between query names are likely to be a common frustration if there is no established
naming pattern.
Finally, using named queries allows for JPQL queries to be overridden with SQL queries or
even with vendor-specific languages and expression frameworks. For applications migrating
from an existing object-relational mapping solution, it is quite likely that the vendor will provide
some support for invoking their existing query solution using the named query facility in
the Java Persistence API. We will discuss SQL named queries in Chapter 9.
Report Queries
If you are executing queries that return entities for reporting purposes and have no intention
of modifying the results, consider executing queries using a transaction-scoped entity manager
but outside of a transaction. The persistence provider may be able to detect the lack of a
transaction and optimize the results for detachment, often by skipping some of the steps
required to create an interim managed version of the entity results.
Likewise, if an entity is expensive to construct due to eager relationships or a complex
table mapping, consider selecting individual entity properties using a projection query instead
of retrieving the full entity result. If all you need is the name and office phone number for 500
employees, selecting only those two fields is likely to be far more efficient than fully constructing
1,000 entity instances.

Query Hints
It is quite likely that vendors will entice you with a variety of hints to enable different performance
optimizations for queries. Query hints may well be an essential tool in meeting your
performance expectations. We strongly advise, however, that you resist the urge to embed
query hints in your application code. The ideal location for query hints is in an XML mapping
file (which we will be describing in Chapter 10), or at the very least as part of a named query
definition. Hints are often highly dependent on the target platform. and may well change over
time as different aspects of the application impact the overall balance of performance. Keep
hints decoupled from your code if at all possible.
Stateless Session Beans
We tried to demonstrate as many examples as possible in the context of a stateless session bean
method, as we believe that this is the best way to organize queries in a Java EE application.
Using the stateless session bean has a number of benefits over simply embedding queries all
over the place in application code:
• Clients can execute queries by invoking an appropriately named business method
instead of relying on a cryptic query name or multiple copies of the same query string.
• Stateless session bean methods can optimize their transaction usage depending on
whether or not the results need to be managed or detached.
• Using a transaction-scoped persistence context ensures that large numbers of entity
instances don’t remain managed long after they are needed.
• For existing entity bean applications, the stateless session bean is the ideal vehicle for
migrating finder queries away from the entity bean home interface. This is not to say that other components are unsuitable locations for queries, but stateless
session beans are a well-established best practice for hosting queries in the Java EE
environment.
Bulk Update and Delete
If bulk update and delete operations must be used, ensure that they are executed only in an isolated
transaction where no other changes are being made. There are many ways in which these
queries can negatively impact an active persistence context. Interweaving these queries with
other non-bulk operations requires careful management by the application.
Entity versioning and locking requires special consideration when bulk update operations
are used. Bulk delete operations can have wide ranging ramifications depending on how well
the persistence provider can react and adjust entity caching in response. Therefore we view
bulk update and delete operations as being highly specialized, to be used with care.
Provider Differences
Take time to become familiar with the SQL that your persistence provider generates for different
JPQL queries. Although understanding SQL is not necessary for writing JPQL queries,knowing what happens in response to the various JPQL operations is an essential part of performance
tuning. Joins in JPQL are not always explicit, and you may find yourself surprised at
the complex SQL generated for a seemingly simple JPQL query.
The benefits of features such as query paging are also dependent on the approach used
by your persistence provider. There are a number of different techniques that can be used to
accomplish pagination, many of which suffer from performance and scalability issues.
Because the Java Persistence API can’t dictate a particular approach that will work well in all
cases, become familiar with the approach used by your provider and whether or not it is
configurable.
Finally, understanding the provider strategy for when and how often it flushes the persistence
context is necessary before looking at optimizations such as changing the flush mode.
Depending on the caching architecture and query optimizations used by a provider, changing
the flush mode may or may not make a difference to your application.