[JBoss JIRA] (WFLY-12674) wildfly.jpa.skipquerydetach set to true, will now skip clearing of query results
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12674?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-12674:
--------------------------------
Description:
Introduce wildfly.jpa.skipquerydetach that defaults to false (to wrap query objects with detacher that clears query results when obtained) but could be set to true, for JBoss AS 5/6 compatibility. This could of been part of [WFLY-3674] but was overlooked.
An example of setting wildfly.jpa.skipquerydetach to true, so that the various query detacher will not be used (e.g. underlying query is returned instead of instance of QueryNonTxInvocationDetacher/TypedQueryNonTxInvocationDetacher/StoredProcedureQueryNonTxInvocationDetacher wrapper):
{code}
<property name="wildfly.jpa.skipquerydetach" value="true" />
{code}
The below reference notes are more for background information but provide the explanation of why the AS5/6 way of detaching loaded entities changed later, to ensure the returned results from Query objects, are detached, instead of the current persistence context at the time of creating the query object, as per feedback below from JPA lead Linda DeMichiel.
[From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
{code}
>>>>> Perhaps a clearer proposal could be:
>>>>>
>>>>> "
>>>>> If the entity manager is invoked outside the scope of a transaction,
>>>>> any entities loaded from the database will
>>>>> immediately become detached at the end of the container level method
>>>>> invocation call (e.g. when the session bean method
>>>>> ends).
>>>>> "
>>>>
>>>> Ah, thanks. That is not the intended semantics. Rather it is that the
>>>> persistence context is created to service the method call that is made
>>>> on the entity manager only. It doesn't have the duration of a business
>>>> method invocation.
>>>
>>> Is it really?
>>>
>>
>> Yes. See also section 3.8.7, which is quite explicit with regard to
>> queries.
>> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
>
> My updated proposal for the 7.6.2 wording is:
>
> "
> If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> immediately become detached at the end of the entity manager method call.
> "
OK, sure + "... or query invocation"
{code}
Note that we (JPA expert group) missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
{quote}
7.6.2 Container-managed Transaction-scoped Persistence Context
The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
{quote}
[Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
{code}
public Query createQuery(String ejbqlString)
{
EntityManager em = getEntityManager();
detachEntitiesIfNoTx(em);
return em.createQuery(ejbqlString);
}
{code}
Also of reference, is from issue description [WFLY-3674]:
{quote}
For compatibility with earlier JBoss application server versions (5.0/6.0), add an extension that allows the persistence context to last until the referencing persistence context is closed.
For example, in a session method that has no active JTA transaction, entities returned, will not cleared from the persistence context, until the session method completes. This extension is only introduced to allow compatibility with older application server versions.
{quote}
[WFLY-12674] is about doing the same for Queries (if wildfly.jpa.skipquerydetach is set to true).
was:
Introduce wildfly.jpa.skipquerydetach that defaults to false (to wrap query objects with detacher that clears query results when obtained) but could be set to true, for JBoss AS 5/6 compatibility. This could of been part of [WFLY-3674] but was overlooked.
An example of setting wildfly.jpa.skipquerydetach to true, so that the various query detacher will not be used (e.g. underlying query is returned instead of instance of QueryNonTxInvocationDetacher/TypedQueryNonTxInvocationDetacher/StoredProcedureQueryNonTxInvocationDetacher wrapper):
{code}
<property name="wildfly.jpa.skipquerydetach" value="true" />
{code}
The below reference notes are more for background information but provide the explanation of why the AS5/6 way of detaching loaded entities changed later, to ensure the returned results from Query objects, are detached, instead of the current persistence context at the time of creating the query object, as per feedback below from JPA lead Linda DeMichiel.
[From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
{code}
>>>>> Perhaps a clearer proposal could be:
>>>>>
>>>>> "
>>>>> If the entity manager is invoked outside the scope of a transaction,
>>>>> any entities loaded from the database will
>>>>> immediately become detached at the end of the container level method
>>>>> invocation call (e.g. when the session bean method
>>>>> ends).
>>>>> "
>>>>
>>>> Ah, thanks. That is not the intended semantics. Rather it is that the
>>>> persistence context is created to service the method call that is made
>>>> on the entity manager only. It doesn't have the duration of a business
>>>> method invocation.
>>>
>>> Is it really?
>>>
>>
>> Yes. See also section 3.8.7, which is quite explicit with regard to
>> queries.
>> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
>
> My updated proposal for the 7.6.2 wording is:
>
> "
> If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> immediately become detached at the end of the entity manager method call.
> "
OK, sure + "... or query invocation"
{code}
Note that we (JPA expert group) missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
{quote}
7.6.2 Container-managed Transaction-scoped Persistence Context
The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
{quote}
[Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
{code}
public Query createQuery(String ejbqlString)
{
EntityManager em = getEntityManager();
detachEntitiesIfNoTx(em);
return em.createQuery(ejbqlString);
}
{code}
Also of reference, is from issue description [WFLY-3674]:
{quote}
For compatibility with earlier JBoss application server versions (5.0/6.0), add an extension that allows the persistence context to last until the referencing persistence context is closed.
For example, in a session method that has no active JTA transaction, entities returned, will not cleared from the persistence context, until the session method completes. This extension is only introduced to allow compatibility with older application server versions.
{quote}
> wildfly.jpa.skipquerydetach set to true, will now skip clearing of query results
> --------------------------------------------------------------------------------
>
> Key: WFLY-12674
> URL: https://issues.jboss.org/browse/WFLY-12674
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
> Fix For: 19.0.0.Beta1
>
>
> Introduce wildfly.jpa.skipquerydetach that defaults to false (to wrap query objects with detacher that clears query results when obtained) but could be set to true, for JBoss AS 5/6 compatibility. This could of been part of [WFLY-3674] but was overlooked.
> An example of setting wildfly.jpa.skipquerydetach to true, so that the various query detacher will not be used (e.g. underlying query is returned instead of instance of QueryNonTxInvocationDetacher/TypedQueryNonTxInvocationDetacher/StoredProcedureQueryNonTxInvocationDetacher wrapper):
> {code}
> <property name="wildfly.jpa.skipquerydetach" value="true" />
> {code}
> The below reference notes are more for background information but provide the explanation of why the AS5/6 way of detaching loaded entities changed later, to ensure the returned results from Query objects, are detached, instead of the current persistence context at the time of creating the query object, as per feedback below from JPA lead Linda DeMichiel.
> [From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
> {code}
> >>>>> Perhaps a clearer proposal could be:
> >>>>>
> >>>>> "
> >>>>> If the entity manager is invoked outside the scope of a transaction,
> >>>>> any entities loaded from the database will
> >>>>> immediately become detached at the end of the container level method
> >>>>> invocation call (e.g. when the session bean method
> >>>>> ends).
> >>>>> "
> >>>>
> >>>> Ah, thanks. That is not the intended semantics. Rather it is that the
> >>>> persistence context is created to service the method call that is made
> >>>> on the entity manager only. It doesn't have the duration of a business
> >>>> method invocation.
> >>>
> >>> Is it really?
> >>>
> >>
> >> Yes. See also section 3.8.7, which is quite explicit with regard to
> >> queries.
> >> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
> >
> > My updated proposal for the 7.6.2 wording is:
> >
> > "
> > If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> > immediately become detached at the end of the entity manager method call.
> > "
> OK, sure + "... or query invocation"
> {code}
> Note that we (JPA expert group) missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
> {quote}
> 7.6.2 Container-managed Transaction-scoped Persistence Context
> The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
> A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
> {quote}
> [Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
> {code}
> public Query createQuery(String ejbqlString)
> {
> EntityManager em = getEntityManager();
> detachEntitiesIfNoTx(em);
> return em.createQuery(ejbqlString);
> }
> {code}
> Also of reference, is from issue description [WFLY-3674]:
> {quote}
> For compatibility with earlier JBoss application server versions (5.0/6.0), add an extension that allows the persistence context to last until the referencing persistence context is closed.
> For example, in a session method that has no active JTA transaction, entities returned, will not cleared from the persistence context, until the session method completes. This extension is only introduced to allow compatibility with older application server versions.
> {quote}
> [WFLY-12674] is about doing the same for Queries (if wildfly.jpa.skipquerydetach is set to true).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
- 1
- 0
[JBoss JIRA] (WFLY-12674) wildfly.jpa.skipquerydetach set to true, will now skip clearing of query results
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12674?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-12674:
--------------------------------
Description:
Introduce wildfly.jpa.skipquerydetach that defaults to false (to wrap query objects with detacher that clears query results when obtained) but could be set to true, for JBoss AS 5/6 compatibility. This could of been part of [WFLY-3674] but was overlooked.
An example of setting wildfly.jpa.skipquerydetach to true, so that the various query detacher will not be used (e.g. underlying query is returned instead of instance of QueryNonTxInvocationDetacher/TypedQueryNonTxInvocationDetacher/StoredProcedureQueryNonTxInvocationDetacher wrapper):
{code}
<property name="wildfly.jpa.skipquerydetach" value="true" />
{code}
The below reference notes are more for background information but provide the explanation of why the AS5/6 way of detaching loaded entities changed later, to ensure the returned results from Query objects, are detached, instead of the current persistence context at the time of creating the query object, as per feedback below from JPA lead Linda DeMichiel.
[From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
{code}
>>>>> Perhaps a clearer proposal could be:
>>>>>
>>>>> "
>>>>> If the entity manager is invoked outside the scope of a transaction,
>>>>> any entities loaded from the database will
>>>>> immediately become detached at the end of the container level method
>>>>> invocation call (e.g. when the session bean method
>>>>> ends).
>>>>> "
>>>>
>>>> Ah, thanks. That is not the intended semantics. Rather it is that the
>>>> persistence context is created to service the method call that is made
>>>> on the entity manager only. It doesn't have the duration of a business
>>>> method invocation.
>>>
>>> Is it really?
>>>
>>
>> Yes. See also section 3.8.7, which is quite explicit with regard to
>> queries.
>> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
>
> My updated proposal for the 7.6.2 wording is:
>
> "
> If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> immediately become detached at the end of the entity manager method call.
> "
OK, sure + "... or query invocation"
{code}
Note that we (JPA expert group) missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
{quote}
7.6.2 Container-managed Transaction-scoped Persistence Context
The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
{quote}
[Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
{code}
public Query createQuery(String ejbqlString)
{
EntityManager em = getEntityManager();
detachEntitiesIfNoTx(em);
return em.createQuery(ejbqlString);
}
{code}
Also of reference, is from issue description [WFLY-3674]:
{quote}
For compatibility with earlier JBoss application server versions (5.0/6.0), add an extension that allows the persistence context to last until the referencing persistence context is closed.
For example, in a session method that has no active JTA transaction, entities returned, will not cleared from the persistence context, until the session method completes. This extension is only introduced to allow compatibility with older application server versions.
{quote}
was:
Introduce wildfly.jpa.skipquerydetach that defaults to false (to wrap query objects with detacher that clears query results when obtained) but could be set to true, for JBoss AS 5/6 compatibility. This could of been part of [WFLY-3674] but was overlooked.
An example of setting wildfly.jpa.skipquerydetach to true, so that the various query detacher will not be used (e.g. underlying query is returned instead of instance of QueryNonTxInvocationDetacher/TypedQueryNonTxInvocationDetacher/StoredProcedureQueryNonTxInvocationDetacher wrapper):
{code}
<property name="wildfly.jpa.skipquerydetach" value="true" />
{code}
The below reference notes are more for background information but provide the explanation of why the AS5/6 way of detaching loaded entities changed later, to ensure the returned results from Query objects, are detached, instead of the current persistence context at the time of creating the query object, as per feedback below from JPA lead Linda DeMichiel.
[From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
{code}
>>>>> Perhaps a clearer proposal could be:
>>>>>
>>>>> "
>>>>> If the entity manager is invoked outside the scope of a transaction,
>>>>> any entities loaded from the database will
>>>>> immediately become detached at the end of the container level method
>>>>> invocation call (e.g. when the session bean method
>>>>> ends).
>>>>> "
>>>>
>>>> Ah, thanks. That is not the intended semantics. Rather it is that the
>>>> persistence context is created to service the method call that is made
>>>> on the entity manager only. It doesn't have the duration of a business
>>>> method invocation.
>>>
>>> Is it really?
>>>
>>
>> Yes. See also section 3.8.7, which is quite explicit with regard to
>> queries.
>> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
>
> My updated proposal for the 7.6.2 wording is:
>
> "
> If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> immediately become detached at the end of the entity manager method call.
> "
OK, sure + "... or query invocation"
{code}
Note that we missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
{quote}
7.6.2 Container-managed Transaction-scoped Persistence Context
The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
{quote}
[Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
{code}
public Query createQuery(String ejbqlString)
{
EntityManager em = getEntityManager();
detachEntitiesIfNoTx(em);
return em.createQuery(ejbqlString);
}
{code}
Also of reference, is from issue description [WFLY-3674]:
{quote}
For compatibility with earlier JBoss application server versions (5.0/6.0), add an extension that allows the persistence context to last until the referencing persistence context is closed.
For example, in a session method that has no active JTA transaction, entities returned, will not cleared from the persistence context, until the session method completes. This extension is only introduced to allow compatibility with older application server versions.
{quote}
> wildfly.jpa.skipquerydetach set to true, will now skip clearing of query results
> --------------------------------------------------------------------------------
>
> Key: WFLY-12674
> URL: https://issues.jboss.org/browse/WFLY-12674
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
> Fix For: 19.0.0.Beta1
>
>
> Introduce wildfly.jpa.skipquerydetach that defaults to false (to wrap query objects with detacher that clears query results when obtained) but could be set to true, for JBoss AS 5/6 compatibility. This could of been part of [WFLY-3674] but was overlooked.
> An example of setting wildfly.jpa.skipquerydetach to true, so that the various query detacher will not be used (e.g. underlying query is returned instead of instance of QueryNonTxInvocationDetacher/TypedQueryNonTxInvocationDetacher/StoredProcedureQueryNonTxInvocationDetacher wrapper):
> {code}
> <property name="wildfly.jpa.skipquerydetach" value="true" />
> {code}
> The below reference notes are more for background information but provide the explanation of why the AS5/6 way of detaching loaded entities changed later, to ensure the returned results from Query objects, are detached, instead of the current persistence context at the time of creating the query object, as per feedback below from JPA lead Linda DeMichiel.
> [From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
> {code}
> >>>>> Perhaps a clearer proposal could be:
> >>>>>
> >>>>> "
> >>>>> If the entity manager is invoked outside the scope of a transaction,
> >>>>> any entities loaded from the database will
> >>>>> immediately become detached at the end of the container level method
> >>>>> invocation call (e.g. when the session bean method
> >>>>> ends).
> >>>>> "
> >>>>
> >>>> Ah, thanks. That is not the intended semantics. Rather it is that the
> >>>> persistence context is created to service the method call that is made
> >>>> on the entity manager only. It doesn't have the duration of a business
> >>>> method invocation.
> >>>
> >>> Is it really?
> >>>
> >>
> >> Yes. See also section 3.8.7, which is quite explicit with regard to
> >> queries.
> >> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
> >
> > My updated proposal for the 7.6.2 wording is:
> >
> > "
> > If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> > immediately become detached at the end of the entity manager method call.
> > "
> OK, sure + "... or query invocation"
> {code}
> Note that we (JPA expert group) missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
> {quote}
> 7.6.2 Container-managed Transaction-scoped Persistence Context
> The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
> A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
> {quote}
> [Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
> {code}
> public Query createQuery(String ejbqlString)
> {
> EntityManager em = getEntityManager();
> detachEntitiesIfNoTx(em);
> return em.createQuery(ejbqlString);
> }
> {code}
> Also of reference, is from issue description [WFLY-3674]:
> {quote}
> For compatibility with earlier JBoss application server versions (5.0/6.0), add an extension that allows the persistence context to last until the referencing persistence context is closed.
> For example, in a session method that has no active JTA transaction, entities returned, will not cleared from the persistence context, until the session method completes. This extension is only introduced to allow compatibility with older application server versions.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
- 1
- 0
[JBoss JIRA] (WFLY-12674) wildfly.jpa.skipquerydetach set to true, will now skip clearing of query results
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12674?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-12674:
--------------------------------
Fix Version/s: 19.0.0.Beta1
> wildfly.jpa.skipquerydetach set to true, will now skip clearing of query results
> --------------------------------------------------------------------------------
>
> Key: WFLY-12674
> URL: https://issues.jboss.org/browse/WFLY-12674
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
> Fix For: 19.0.0.Beta1
>
>
> Introduce wildfly.jpa.skipquerydetach that defaults to false (to wrap query objects with detacher that clears query results when obtained) but could be set to true, for JBoss AS 5/6 compatibility. This could of been part of [WFLY-3674] but was overlooked.
> An example of setting wildfly.jpa.skipquerydetach to true, so that the various query detacher will not be used (e.g. underlying query is returned instead of instance of QueryNonTxInvocationDetacher/TypedQueryNonTxInvocationDetacher/StoredProcedureQueryNonTxInvocationDetacher wrapper):
> {code}
> <property name="wildfly.jpa.skipquerydetach" value="true" />
> {code}
> The below reference notes are more for background information but provide the explanation of why the AS5/6 way of detaching loaded entities changed later, to ensure the returned results from Query objects, are detached, instead of the current persistence context at the time of creating the query object, as per feedback below from JPA lead Linda DeMichiel.
> [From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
> {code}
> >>>>> Perhaps a clearer proposal could be:
> >>>>>
> >>>>> "
> >>>>> If the entity manager is invoked outside the scope of a transaction,
> >>>>> any entities loaded from the database will
> >>>>> immediately become detached at the end of the container level method
> >>>>> invocation call (e.g. when the session bean method
> >>>>> ends).
> >>>>> "
> >>>>
> >>>> Ah, thanks. That is not the intended semantics. Rather it is that the
> >>>> persistence context is created to service the method call that is made
> >>>> on the entity manager only. It doesn't have the duration of a business
> >>>> method invocation.
> >>>
> >>> Is it really?
> >>>
> >>
> >> Yes. See also section 3.8.7, which is quite explicit with regard to
> >> queries.
> >> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
> >
> > My updated proposal for the 7.6.2 wording is:
> >
> > "
> > If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> > immediately become detached at the end of the entity manager method call.
> > "
> OK, sure + "... or query invocation"
> {code}
> Note that we missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
> {quote}
> 7.6.2 Container-managed Transaction-scoped Persistence Context
> The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
> A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
> {quote}
> [Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
> {code}
> public Query createQuery(String ejbqlString)
> {
> EntityManager em = getEntityManager();
> detachEntitiesIfNoTx(em);
> return em.createQuery(ejbqlString);
> }
> {code}
> Also of reference, is from issue description [WFLY-3674]:
> {quote}
> For compatibility with earlier JBoss application server versions (5.0/6.0), add an extension that allows the persistence context to last until the referencing persistence context is closed.
> For example, in a session method that has no active JTA transaction, entities returned, will not cleared from the persistence context, until the session method completes. This extension is only introduced to allow compatibility with older application server versions.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
- 1
- 0
[JBoss JIRA] (WFLY-12674) wildfly.jpa.skipquerydetach set to true, will now skip clearing of query results
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12674?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-12674:
--------------------------------
Summary: wildfly.jpa.skipquerydetach set to true, will now skip clearing of query results (was: Introduce wildfly.jpa.skipquerydetach property to enhance deferDetach extension)
> wildfly.jpa.skipquerydetach set to true, will now skip clearing of query results
> --------------------------------------------------------------------------------
>
> Key: WFLY-12674
> URL: https://issues.jboss.org/browse/WFLY-12674
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
>
> Introduce wildfly.jpa.skipquerydetach that defaults to false (to wrap query objects with detacher that clears query results when obtained) but could be set to true, for JBoss AS 5/6 compatibility. This could of been part of [WFLY-3674] but was overlooked.
> An example of setting wildfly.jpa.skipquerydetach to true, so that the various query detacher will not be used (e.g. underlying query is returned instead of instance of QueryNonTxInvocationDetacher/TypedQueryNonTxInvocationDetacher/StoredProcedureQueryNonTxInvocationDetacher wrapper):
> {code}
> <property name="wildfly.jpa.skipquerydetach" value="true" />
> {code}
> The below reference notes are more for background information but provide the explanation of why the AS5/6 way of detaching loaded entities changed later, to ensure the returned results from Query objects, are detached, instead of the current persistence context at the time of creating the query object, as per feedback below from JPA lead Linda DeMichiel.
> [From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
> {code}
> >>>>> Perhaps a clearer proposal could be:
> >>>>>
> >>>>> "
> >>>>> If the entity manager is invoked outside the scope of a transaction,
> >>>>> any entities loaded from the database will
> >>>>> immediately become detached at the end of the container level method
> >>>>> invocation call (e.g. when the session bean method
> >>>>> ends).
> >>>>> "
> >>>>
> >>>> Ah, thanks. That is not the intended semantics. Rather it is that the
> >>>> persistence context is created to service the method call that is made
> >>>> on the entity manager only. It doesn't have the duration of a business
> >>>> method invocation.
> >>>
> >>> Is it really?
> >>>
> >>
> >> Yes. See also section 3.8.7, which is quite explicit with regard to
> >> queries.
> >> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
> >
> > My updated proposal for the 7.6.2 wording is:
> >
> > "
> > If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> > immediately become detached at the end of the entity manager method call.
> > "
> OK, sure + "... or query invocation"
> {code}
> Note that we missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
> {quote}
> 7.6.2 Container-managed Transaction-scoped Persistence Context
> The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
> A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
> {quote}
> [Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
> {code}
> public Query createQuery(String ejbqlString)
> {
> EntityManager em = getEntityManager();
> detachEntitiesIfNoTx(em);
> return em.createQuery(ejbqlString);
> }
> {code}
> Also of reference, is from issue description [WFLY-3674]:
> {quote}
> For compatibility with earlier JBoss application server versions (5.0/6.0), add an extension that allows the persistence context to last until the referencing persistence context is closed.
> For example, in a session method that has no active JTA transaction, entities returned, will not cleared from the persistence context, until the session method completes. This extension is only introduced to allow compatibility with older application server versions.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
- 1
- 0
[JBoss JIRA] (DROOLS-3566) DMN:Detailed interactions for creating and managing DRDs
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3566?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton commented on DROOLS-3566:
-------------------------------------------
Thanks [~tirelli] , I will add the filtered view, good catch! WRT the context menu - if we need alternate ways to provide the same actions, I'm not sure we offer that atm. I wasn't aware of this being a requirement outside of the Data Types tab. I don't believe we offer redundant means in decision tables or etc., is that correct [~manstis]? Early on, the field suggested toolbar controls for novice users, should I be considering that now?
> DMN:Detailed interactions for creating and managing DRDs
> --------------------------------------------------------
>
> Key: DROOLS-3566
> URL: https://issues.jboss.org/browse/DROOLS-3566
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: contextual-menu.png
>
>
> Canvas node actions related to grouping and assigning to DRDs.
> * As a user I want to easily select and group nodes on the canvas so that I can add them to a DRD or to create a new DRD.
> (TBD) As a user I want to be able to be able to use the Navigator tree to create DRD's and assign canvas nodes, so that I can easily modify my graph views.
> Notes:
> Navigator Tree actions TBD:
> * Drag nodes to DRDs.
> * Contextual menu for tree objects?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
- 1
- 0
[JBoss JIRA] (WFLY-12674) Introduce wildfly.jpa.skipquerydetach property to enhance deferDetach extension
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12674?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-12674:
--------------------------------
Description:
Introduce wildfly.jpa.skipquerydetach that defaults to false (to wrap query objects with detacher that clears query results when obtained) but could be set to true, for JBoss AS 5/6 compatibility. This could of been part of [WFLY-3674] but was overlooked.
An example of setting wildfly.jpa.skipquerydetach to true, so that the various query detacher will not be used (e.g. underlying query is returned instead of instance of QueryNonTxInvocationDetacher/TypedQueryNonTxInvocationDetacher/StoredProcedureQueryNonTxInvocationDetacher wrapper):
{code}
<property name="wildfly.jpa.skipquerydetach" value="true" />
{code}
The below reference notes are more for background information but provide the explanation of why the AS5/6 way of detaching loaded entities changed later, to ensure the returned results from Query objects, are detached, instead of the current persistence context at the time of creating the query object, as per feedback below from JPA lead Linda DeMichiel.
[From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
{code}
>>>>> Perhaps a clearer proposal could be:
>>>>>
>>>>> "
>>>>> If the entity manager is invoked outside the scope of a transaction,
>>>>> any entities loaded from the database will
>>>>> immediately become detached at the end of the container level method
>>>>> invocation call (e.g. when the session bean method
>>>>> ends).
>>>>> "
>>>>
>>>> Ah, thanks. That is not the intended semantics. Rather it is that the
>>>> persistence context is created to service the method call that is made
>>>> on the entity manager only. It doesn't have the duration of a business
>>>> method invocation.
>>>
>>> Is it really?
>>>
>>
>> Yes. See also section 3.8.7, which is quite explicit with regard to
>> queries.
>> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
>
> My updated proposal for the 7.6.2 wording is:
>
> "
> If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> immediately become detached at the end of the entity manager method call.
> "
OK, sure + "... or query invocation"
{code}
Note that we missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
{quote}
7.6.2 Container-managed Transaction-scoped Persistence Context
The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
{quote}
[Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
{code}
public Query createQuery(String ejbqlString)
{
EntityManager em = getEntityManager();
detachEntitiesIfNoTx(em);
return em.createQuery(ejbqlString);
}
{code}
Also of reference, is from issue description [WFLY-3674]:
{quote}
For compatibility with earlier JBoss application server versions (5.0/6.0), add an extension that allows the persistence context to last until the referencing persistence context is closed.
For example, in a session method that has no active JTA transaction, entities returned, will not cleared from the persistence context, until the session method completes. This extension is only introduced to allow compatibility with older application server versions.
{quote}
was:
Introduce wildfly.jpa.skipquerydetach that defaults to false but could be set to true, for JBoss AS 5/6 compatibility. This really should of been part of [WFLY-3674] but was overlooked.
An example of setting wildfly.jpa.skipquerydetach to true, so that the various query detacher will not be used (e.g. underlying query is returned instead of instance of QueryNonTxInvocationDetacher/TypedQueryNonTxInvocationDetacher/StoredProcedureQueryNonTxInvocationDetacher wrapper):
{code}
<property name="wildfly.jpa.skipquerydetach" value="true" />
{code}
The below reference notes are more for background information but provide the explanation of why the AS5/6 way of detaching loaded entities changed later, to ensure the returned results from Query objects, are detached, instead of the current persistence context at the time of creating the query object, as per feedback below from JPA lead Linda DeMichiel.
[From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
{code}
>>>>> Perhaps a clearer proposal could be:
>>>>>
>>>>> "
>>>>> If the entity manager is invoked outside the scope of a transaction,
>>>>> any entities loaded from the database will
>>>>> immediately become detached at the end of the container level method
>>>>> invocation call (e.g. when the session bean method
>>>>> ends).
>>>>> "
>>>>
>>>> Ah, thanks. That is not the intended semantics. Rather it is that the
>>>> persistence context is created to service the method call that is made
>>>> on the entity manager only. It doesn't have the duration of a business
>>>> method invocation.
>>>
>>> Is it really?
>>>
>>
>> Yes. See also section 3.8.7, which is quite explicit with regard to
>> queries.
>> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
>
> My updated proposal for the 7.6.2 wording is:
>
> "
> If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> immediately become detached at the end of the entity manager method call.
> "
OK, sure + "... or query invocation"
{code}
Note that we missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
{quote}
7.6.2 Container-managed Transaction-scoped Persistence Context
The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
{quote}
[Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
{code}
public Query createQuery(String ejbqlString)
{
EntityManager em = getEntityManager();
detachEntitiesIfNoTx(em);
return em.createQuery(ejbqlString);
}
{code}
Also of reference, is from issue description [WFLY-3674]:
{quote}
For compatibility with earlier JBoss application server versions (5.0/6.0), add an extension that allows the persistence context to last until the referencing persistence context is closed.
For example, in a session method that has no active JTA transaction, entities returned, will not cleared from the persistence context, until the session method completes. This extension is only introduced to allow compatibility with older application server versions.
{quote}
> Introduce wildfly.jpa.skipquerydetach property to enhance deferDetach extension
> -------------------------------------------------------------------------------
>
> Key: WFLY-12674
> URL: https://issues.jboss.org/browse/WFLY-12674
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
>
> Introduce wildfly.jpa.skipquerydetach that defaults to false (to wrap query objects with detacher that clears query results when obtained) but could be set to true, for JBoss AS 5/6 compatibility. This could of been part of [WFLY-3674] but was overlooked.
> An example of setting wildfly.jpa.skipquerydetach to true, so that the various query detacher will not be used (e.g. underlying query is returned instead of instance of QueryNonTxInvocationDetacher/TypedQueryNonTxInvocationDetacher/StoredProcedureQueryNonTxInvocationDetacher wrapper):
> {code}
> <property name="wildfly.jpa.skipquerydetach" value="true" />
> {code}
> The below reference notes are more for background information but provide the explanation of why the AS5/6 way of detaching loaded entities changed later, to ensure the returned results from Query objects, are detached, instead of the current persistence context at the time of creating the query object, as per feedback below from JPA lead Linda DeMichiel.
> [From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
> {code}
> >>>>> Perhaps a clearer proposal could be:
> >>>>>
> >>>>> "
> >>>>> If the entity manager is invoked outside the scope of a transaction,
> >>>>> any entities loaded from the database will
> >>>>> immediately become detached at the end of the container level method
> >>>>> invocation call (e.g. when the session bean method
> >>>>> ends).
> >>>>> "
> >>>>
> >>>> Ah, thanks. That is not the intended semantics. Rather it is that the
> >>>> persistence context is created to service the method call that is made
> >>>> on the entity manager only. It doesn't have the duration of a business
> >>>> method invocation.
> >>>
> >>> Is it really?
> >>>
> >>
> >> Yes. See also section 3.8.7, which is quite explicit with regard to
> >> queries.
> >> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
> >
> > My updated proposal for the 7.6.2 wording is:
> >
> > "
> > If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> > immediately become detached at the end of the entity manager method call.
> > "
> OK, sure + "... or query invocation"
> {code}
> Note that we missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
> {quote}
> 7.6.2 Container-managed Transaction-scoped Persistence Context
> The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
> A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
> {quote}
> [Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
> {code}
> public Query createQuery(String ejbqlString)
> {
> EntityManager em = getEntityManager();
> detachEntitiesIfNoTx(em);
> return em.createQuery(ejbqlString);
> }
> {code}
> Also of reference, is from issue description [WFLY-3674]:
> {quote}
> For compatibility with earlier JBoss application server versions (5.0/6.0), add an extension that allows the persistence context to last until the referencing persistence context is closed.
> For example, in a session method that has no active JTA transaction, entities returned, will not cleared from the persistence context, until the session method completes. This extension is only introduced to allow compatibility with older application server versions.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
- 1
- 0
[JBoss JIRA] (WFLY-12667) Upgrade Hibernate Validator to 6.0.18
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12667?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-12667:
---------------------------------
Summary: Upgrade Hibernate Validator to 6.0.18 (was: Upgrade Hibernate Validator to 6.0.17)
> Upgrade Hibernate Validator to 6.0.18
> -------------------------------------
>
> Key: WFLY-12667
> URL: https://issues.jboss.org/browse/WFLY-12667
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Bean Validation
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
> Fix For: 19.0.0.Beta1
>
>
> Tracker for Hibernate Validator upgrade to pick up incorporated fixes.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
- 1
- 0
[JBoss JIRA] (WFLY-12674) Introduce wildfly.jpa.skipquerydetach property to enhance deferDetach extension
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12674?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-12674:
--------------------------------
Description:
Introduce wildfly.jpa.skipquerydetach that defaults to false but could be set to true, for JBoss AS 5/6 compatibility. This really should of been part of [WFLY-3674] but was overlooked.
An example of setting wildfly.jpa.skipquerydetach to true, so that the various query detacher will not be used (e.g. underlying query is returned instead of instance of QueryNonTxInvocationDetacher/TypedQueryNonTxInvocationDetacher/StoredProcedureQueryNonTxInvocationDetacher wrapper):
{code}
<property name="wildfly.jpa.skipquerydetach" value="true" />
{code}
The below reference notes are more for background information but provide the explanation of why the AS5/6 way of detaching loaded entities changed later, to ensure the returned results from Query objects, are detached, instead of the current persistence context at the time of creating the query object, as per feedback below from JPA lead Linda DeMichiel.
[From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
{code}
>>>>> Perhaps a clearer proposal could be:
>>>>>
>>>>> "
>>>>> If the entity manager is invoked outside the scope of a transaction,
>>>>> any entities loaded from the database will
>>>>> immediately become detached at the end of the container level method
>>>>> invocation call (e.g. when the session bean method
>>>>> ends).
>>>>> "
>>>>
>>>> Ah, thanks. That is not the intended semantics. Rather it is that the
>>>> persistence context is created to service the method call that is made
>>>> on the entity manager only. It doesn't have the duration of a business
>>>> method invocation.
>>>
>>> Is it really?
>>>
>>
>> Yes. See also section 3.8.7, which is quite explicit with regard to
>> queries.
>> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
>
> My updated proposal for the 7.6.2 wording is:
>
> "
> If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> immediately become detached at the end of the entity manager method call.
> "
OK, sure + "... or query invocation"
{code}
Note that we missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
{quote}
7.6.2 Container-managed Transaction-scoped Persistence Context
The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
{quote}
[Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
{code}
public Query createQuery(String ejbqlString)
{
EntityManager em = getEntityManager();
detachEntitiesIfNoTx(em);
return em.createQuery(ejbqlString);
}
{code}
Also of reference, is from issue description [WFLY-3674]:
{quote}
For compatibility with earlier JBoss application server versions (5.0/6.0), add an extension that allows the persistence context to last until the referencing persistence context is closed.
For example, in a session method that has no active JTA transaction, entities returned, will not cleared from the persistence context, until the session method completes. This extension is only introduced to allow compatibility with older application server versions.
{quote}
was:
[From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
{code}
>>>>> Perhaps a clearer proposal could be:
>>>>>
>>>>> "
>>>>> If the entity manager is invoked outside the scope of a transaction,
>>>>> any entities loaded from the database will
>>>>> immediately become detached at the end of the container level method
>>>>> invocation call (e.g. when the session bean method
>>>>> ends).
>>>>> "
>>>>
>>>> Ah, thanks. That is not the intended semantics. Rather it is that the
>>>> persistence context is created to service the method call that is made
>>>> on the entity manager only. It doesn't have the duration of a business
>>>> method invocation.
>>>
>>> Is it really?
>>>
>>
>> Yes. See also section 3.8.7, which is quite explicit with regard to
>> queries.
>> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
>
> My updated proposal for the 7.6.2 wording is:
>
> "
> If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> immediately become detached at the end of the entity manager method call.
> "
OK, sure + "... or query invocation"
{code}
Note that we missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
{quote}
7.6.2 Container-managed Transaction-scoped Persistence Context
The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
{quote}
[Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
{code}
public Query createQuery(String ejbqlString)
{
EntityManager em = getEntityManager();
detachEntitiesIfNoTx(em);
return em.createQuery(ejbqlString);
}
{code}
Also of reference, is from issue description [WFLY-3674]:
{quote}
For compatibility with earlier JBoss application server versions (5.0/6.0), add an extension that allows the persistence context to last until the referencing persistence context is closed.
For example, in a session method that has no active JTA transaction, entities returned, will not cleared from the persistence context, until the session method completes. This extension is only introduced to allow compatibility with older application server versions.
{quote}
> Introduce wildfly.jpa.skipquerydetach property to enhance deferDetach extension
> -------------------------------------------------------------------------------
>
> Key: WFLY-12674
> URL: https://issues.jboss.org/browse/WFLY-12674
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
>
> Introduce wildfly.jpa.skipquerydetach that defaults to false but could be set to true, for JBoss AS 5/6 compatibility. This really should of been part of [WFLY-3674] but was overlooked.
> An example of setting wildfly.jpa.skipquerydetach to true, so that the various query detacher will not be used (e.g. underlying query is returned instead of instance of QueryNonTxInvocationDetacher/TypedQueryNonTxInvocationDetacher/StoredProcedureQueryNonTxInvocationDetacher wrapper):
> {code}
> <property name="wildfly.jpa.skipquerydetach" value="true" />
> {code}
> The below reference notes are more for background information but provide the explanation of why the AS5/6 way of detaching loaded entities changed later, to ensure the returned results from Query objects, are detached, instead of the current persistence context at the time of creating the query object, as per feedback below from JPA lead Linda DeMichiel.
> [From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
> {code}
> >>>>> Perhaps a clearer proposal could be:
> >>>>>
> >>>>> "
> >>>>> If the entity manager is invoked outside the scope of a transaction,
> >>>>> any entities loaded from the database will
> >>>>> immediately become detached at the end of the container level method
> >>>>> invocation call (e.g. when the session bean method
> >>>>> ends).
> >>>>> "
> >>>>
> >>>> Ah, thanks. That is not the intended semantics. Rather it is that the
> >>>> persistence context is created to service the method call that is made
> >>>> on the entity manager only. It doesn't have the duration of a business
> >>>> method invocation.
> >>>
> >>> Is it really?
> >>>
> >>
> >> Yes. See also section 3.8.7, which is quite explicit with regard to
> >> queries.
> >> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
> >
> > My updated proposal for the 7.6.2 wording is:
> >
> > "
> > If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> > immediately become detached at the end of the entity manager method call.
> > "
> OK, sure + "... or query invocation"
> {code}
> Note that we missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
> {quote}
> 7.6.2 Container-managed Transaction-scoped Persistence Context
> The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
> A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
> {quote}
> [Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
> {code}
> public Query createQuery(String ejbqlString)
> {
> EntityManager em = getEntityManager();
> detachEntitiesIfNoTx(em);
> return em.createQuery(ejbqlString);
> }
> {code}
> Also of reference, is from issue description [WFLY-3674]:
> {quote}
> For compatibility with earlier JBoss application server versions (5.0/6.0), add an extension that allows the persistence context to last until the referencing persistence context is closed.
> For example, in a session method that has no active JTA transaction, entities returned, will not cleared from the persistence context, until the session method completes. This extension is only introduced to allow compatibility with older application server versions.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
- 1
- 0
[JBoss JIRA] (WFLY-12674) Introduce wildfly.jpa.skipquerydetach property to enhance deferDetach extension
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12674?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-12674:
--------------------------------
Summary: Introduce wildfly.jpa.skipquerydetach property to enhance deferDetach extension (was: placeholder for deferDetach issue)
> Introduce wildfly.jpa.skipquerydetach property to enhance deferDetach extension
> -------------------------------------------------------------------------------
>
> Key: WFLY-12674
> URL: https://issues.jboss.org/browse/WFLY-12674
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
>
> [From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
> {code}
> >>>>> Perhaps a clearer proposal could be:
> >>>>>
> >>>>> "
> >>>>> If the entity manager is invoked outside the scope of a transaction,
> >>>>> any entities loaded from the database will
> >>>>> immediately become detached at the end of the container level method
> >>>>> invocation call (e.g. when the session bean method
> >>>>> ends).
> >>>>> "
> >>>>
> >>>> Ah, thanks. That is not the intended semantics. Rather it is that the
> >>>> persistence context is created to service the method call that is made
> >>>> on the entity manager only. It doesn't have the duration of a business
> >>>> method invocation.
> >>>
> >>> Is it really?
> >>>
> >>
> >> Yes. See also section 3.8.7, which is quite explicit with regard to
> >> queries.
> >> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
> >
> > My updated proposal for the 7.6.2 wording is:
> >
> > "
> > If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> > immediately become detached at the end of the entity manager method call.
> > "
> OK, sure + "... or query invocation"
> {code}
> Note that we missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
> {quote}
> 7.6.2 Container-managed Transaction-scoped Persistence Context
> The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
> A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
> {quote}
> [Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
> {code}
> public Query createQuery(String ejbqlString)
> {
> EntityManager em = getEntityManager();
> detachEntitiesIfNoTx(em);
> return em.createQuery(ejbqlString);
> }
> {code}
> Also of reference, is from issue description [WFLY-3674]:
> {quote}
> For compatibility with earlier JBoss application server versions (5.0/6.0), add an extension that allows the persistence context to last until the referencing persistence context is closed.
> For example, in a session method that has no active JTA transaction, entities returned, will not cleared from the persistence context, until the session method completes. This extension is only introduced to allow compatibility with older application server versions.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
- 1
- 0
[JBoss JIRA] (WFLY-12674) placeholder for deferDetach issue
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-12674?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-12674:
--------------------------------
Description:
[From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
{code}
>>>>> Perhaps a clearer proposal could be:
>>>>>
>>>>> "
>>>>> If the entity manager is invoked outside the scope of a transaction,
>>>>> any entities loaded from the database will
>>>>> immediately become detached at the end of the container level method
>>>>> invocation call (e.g. when the session bean method
>>>>> ends).
>>>>> "
>>>>
>>>> Ah, thanks. That is not the intended semantics. Rather it is that the
>>>> persistence context is created to service the method call that is made
>>>> on the entity manager only. It doesn't have the duration of a business
>>>> method invocation.
>>>
>>> Is it really?
>>>
>>
>> Yes. See also section 3.8.7, which is quite explicit with regard to
>> queries.
>> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
>
> My updated proposal for the 7.6.2 wording is:
>
> "
> If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> immediately become detached at the end of the entity manager method call.
> "
OK, sure + "... or query invocation"
{code}
Note that we missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
{quote}
7.6.2 Container-managed Transaction-scoped Persistence Context
The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
{quote}
[Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
{code}
public Query createQuery(String ejbqlString)
{
EntityManager em = getEntityManager();
detachEntitiesIfNoTx(em);
return em.createQuery(ejbqlString);
}
{code}
Also of reference, is from issue description [WFLY-3674]:
{quote}
For compatibility with earlier JBoss application server versions (5.0/6.0), add an extension that allows the persistence context to last until the referencing persistence context is closed.
For example, in a session method that has no active JTA transaction, entities returned, will not cleared from the persistence context, until the session method completes. This extension is only introduced to allow compatibility with older application server versions.
{quote}
was:
[From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
{code}
>>>>> Perhaps a clearer proposal could be:
>>>>>
>>>>> "
>>>>> If the entity manager is invoked outside the scope of a transaction,
>>>>> any entities loaded from the database will
>>>>> immediately become detached at the end of the container level method
>>>>> invocation call (e.g. when the session bean method
>>>>> ends).
>>>>> "
>>>>
>>>> Ah, thanks. That is not the intended semantics. Rather it is that the
>>>> persistence context is created to service the method call that is made
>>>> on the entity manager only. It doesn't have the duration of a business
>>>> method invocation.
>>>
>>> Is it really?
>>>
>>
>> Yes. See also section 3.8.7, which is quite explicit with regard to
>> queries.
>> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
>
> My updated proposal for the 7.6.2 wording is:
>
> "
> If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> immediately become detached at the end of the entity manager method call.
> "
OK, sure + "... or query invocation"
{code}
Note that we missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
{quote}
7.6.2 Container-managed Transaction-scoped Persistence Context
The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
{quote}
[Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
{code}
public Query createQuery(String ejbqlString)
{
EntityManager em = getEntityManager();
detachEntitiesIfNoTx(em);
return em.createQuery(ejbqlString);
}
{code}
> placeholder for deferDetach issue
> ---------------------------------
>
> Key: WFLY-12674
> URL: https://issues.jboss.org/browse/WFLY-12674
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
>
> [From related JPA expert group discussion|https://download.oracle.com/javaee-archive/jpa-spec.java.net/u...]:
> {code}
> >>>>> Perhaps a clearer proposal could be:
> >>>>>
> >>>>> "
> >>>>> If the entity manager is invoked outside the scope of a transaction,
> >>>>> any entities loaded from the database will
> >>>>> immediately become detached at the end of the container level method
> >>>>> invocation call (e.g. when the session bean method
> >>>>> ends).
> >>>>> "
> >>>>
> >>>> Ah, thanks. That is not the intended semantics. Rather it is that the
> >>>> persistence context is created to service the method call that is made
> >>>> on the entity manager only. It doesn't have the duration of a business
> >>>> method invocation.
> >>>
> >>> Is it really?
> >>>
> >>
> >> Yes. See also section 3.8.7, which is quite explicit with regard to
> >> queries.
> >> BTW, these decisions date back to JPA 1.0 (aka EJB 3.0).
> >
> > My updated proposal for the 7.6.2 wording is:
> >
> > "
> > If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
> > immediately become detached at the end of the entity manager method call.
> > "
> OK, sure + "... or query invocation"
> {code}
> Note that we missed Linda's response of "... or query invocation" in the JPA spec update, as the JPA 2.2 spec today states:
> {quote}
> 7.6.2 Container-managed Transaction-scoped Persistence Context
> The application can obtain a container-managed entity manager with transaction-scoped persistence context by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.
> A new persistence context begins when the container-managed entity manager is invoked [84] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. This association of the persistence context with the JTA transaction is independent of the synchronization type of the persistence context and whether the persistence context has been joined to the transaction.
> {quote}
> [Some related AS5/6 JPA container code.|https://anonsvn.jboss.org/repos/jbossas/projects/jpa/trunk/impl/src...] which simply cleared the persistence context as we were creating a new Query, for example see:
> {code}
> public Query createQuery(String ejbqlString)
> {
> EntityManager em = getEntityManager();
> detachEntitiesIfNoTx(em);
> return em.createQuery(ejbqlString);
> }
> {code}
> Also of reference, is from issue description [WFLY-3674]:
> {quote}
> For compatibility with earlier JBoss application server versions (5.0/6.0), add an extension that allows the persistence context to last until the referencing persistence context is closed.
> For example, in a session method that has no active JTA transaction, entities returned, will not cleared from the persistence context, until the session method completes. This extension is only introduced to allow compatibility with older application server versions.
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
- 1
- 0