Hello; our application features lots and lots of named queries. We use
them for a number of reasons which include:
* Single compilation and verification/validation at startup
* Ability for XML overrides
However, there are some queries that have to be dynamic (namely those that
feature ORDER BY clauses that might be logically passed in by the caller,
since the latter cannot be parameterized in a named query). (Think about
the use case of someone clicking on a column header in a table to sort on
that column header, but where you want the sorting to be accomplished on
the server side.)
Although we'd greatly prefer a named query syntax that would permit such
(extremely common!) parameterization, failing that we need to know where
the best place is to build these using the criteria query facilities and
store them in a Java EE 6 application that makes use of JPA. I can think
of several candidates ranging from static Maps to @Singleton EJBs and so
forth.
However, I am not sure what state a criteria-query-built Query is required
to possess or is prohibited from possessing. Are these objects tied in
some manner to the thread that created them, or the currently open
EntityManager, or other things that would prevent them from being built
once and cached somewhere? Is this behavior undefined (in which case I can
make no assumption whatsoever about the associated state, and therefore for
portability and safety must reconstruct these queries again and again)?
I am happy to provide more details as requested. This strikes me as a
really common use case that isn't fully addressed by the JPA specification
which is another reason I brought it up here; my apologies if I'm in the
wrong place.
Best,
Laird
--
http://about.me/lairdnelson