jsr338-experts@jpa-spec.java.net

[jsr338-experts] Re: named queries

From: Gordon Yorke <gordon.yorke_at_oracle.com>
Date: Wed, 13 Apr 2011 10:17:36 -0300

>
> 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?
>
This could be added.
> And then we might also see race conditions, e.g.
Adding a namedQuery with the same name would be expected to replace the
previously defined query (allows for deployment time overriding of
statically defined queries). These are named queries and they are being
scoped to the EMF so defining them concurrently would be a very poor
pattern.
> So I am starting to wonder if this feature is mostly useful in standalone
> Java SE
> environments.
Perhaps what we need is a PreCreateEMF/PreCreateEM event that would
allow users to tweak their properties/queries prior to the provider
creating these artifacts. These events would be useful in all deployments.
--Gordon


Evan Ireland wrote:
> 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
>>>>
>>>>
>
>