Linda,
If I am using an EntityManager, can I check whether I need to add a named
query
or if one has already been added with a particular name?
If thread 1 (let's say session bean) adds a named query to the
EntityManagerFactory, will thread 2 (say also using same session bean) in
the same
process (e.g. Java EE server) be able to use that named query, or will each
thread
need to add its own copy?
Either way, if the query can be shared, or if each thread might need to be
able to
add its own copy, the ability to test if a query has already been added
seems useful.
And then we might also see race conditions, e.g.
if (emf.hasNamedQuery("foo"))
{
Query myQuery = ...;
emf.addNamedQuery("foo", myQuery); // can this fail due to race
condition (query already added by another thread)
}
So I am starting to wonder if this feature is mostly useful in standalone
Java SE
environments.
> -----Original Message-----
> From: Linda DeMichiel [mailto:linda.demichiel_at_oracle.com]
> Sent: Wednesday, 13 April 2011 9:54 a.m.
> To: jsr338-experts_at_jpa-spec.java.net
> Subject: [jsr338-experts] Re: named queries
>
>
>
> On 4/12/2011 1:41 PM, Evan Ireland wrote:
> > Linda,
> >
> > Why is this proposed to be on the EntityManagerFactory, and not the
> > EntityManager?
> >
> > If I use an injected EntityManager, will this feature be useful?
>
> Sorry, I didn't answer this second question. Yes -- it will
> be useful
> in either case. BTW, after my initial post I received an almost
> immediate response from one of the observers of our group asking that
> we please include this feature.
>
> -Linda
>
>
>
> >
> >> -----Original Message-----
> >> From: Linda DeMichiel [mailto:linda.demichiel_at_oracle.com]
> >> Sent: Wednesday, 13 April 2011 6:43 a.m.
> >> To: jsr338-experts_at_jpa-spec.java.net
> >> Subject: [jsr338-experts] named queries
> >>
> >> We've received suggestions to the effect that it would be useful if
> >> queries could be created dynamically (e.g., at initialization time)
> >> and then be assigned names so that they could be used for execution
> >> later.
> >>
> >> These queries would have the same scope as other named queries,
> >> and be associated with the persistence unit.
> >>
> >> For example:
> >>
> >> TypedQuery<Integer> tq = em.createQuery("SELECT e.seniority
> >> FROM Employee e WHERE e.seniority > 10", Integer.class);
> >> emf.addNamedQuery("Employee_Seniority", tq);
> >>
> >> Any configuration of the query object (except for actual parameter
> >> binding) specified when the query was added as a named
> query would be
> >> retained as part of the named query. [I.e., this would include
> >> configuration information like setMaxResults, setHint,
> setFlushMode,
> >> setLockMode, result set mapping information, and information
> >> registered about stored procedure parameters...]
> >>
> >> When the query is executed, information that is settable by means
> >> of the Query API can be overridden. Information that is overridden
> >> does not affect the named query as registered with the EMF, and
> >> thus does not affect subsequent Query objects created by means
> >> of the name via the EntityManager createNamedQuery method.
> >>
> >>
> >> Linda
> >>
> >
>