February 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6586) JPA afterCompletion sync may be called from non-application thread, resolve concurrency concern

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/AS7-6586?page=com.atlassian.jira.plugin.s... ] Scott Marlow updated AS7-6586: ------------------------------ Description: For transaction scoped entity managers, the closing the of entity manager is deferred until after the transaction completes. It is possible that the transaction manager/service may call the Transaction sync from a non-application thread (tx timeout reaper thread or normal completion in remote propagated tx case). Guards need to be added to make sure that a tx timeout, doesn't interfere with normal application usage of the entity manager. I think that there are two main cases to be concerned with that involve the afterCompletion sync being invoked in a non-application thread: # TX reaper or other background thread calls afterCompletion while application thread is in (transaction scope) entityManager invocation. # TX reaper or other background thread calls afterCompletion while application thread is not in (transaction scope) entityManager invocation. Extended persistence contexts do not get closed when the JTA transaction that they are joined to are closed (in case anyone is curious). If we are in #1 above, could we delegate the closing of the EntityManager to the in progress EntityManager invocation (to avoid closing the thread unsafe invocation)? Or prevent the background thread from closing the EntityManager until the current EntityManager invocation completes. Or push the requirement up to the top-level EE container (e.g. managed bean, EJB3, web, ...). The related classes are org.jboss.as.jpa.container.TransactionScopedEntityManager (or AbstractEntityManager) + org.jboss.as.jpa.transaction.TransactionUtil classes. was: For transaction scoped entity managers, the closing the of entity manager is deferred until after the transaction completes. It is possible that the transaction manager/service may call the Transaction sync from a non-application thread (tx timeout reaper thread or normal completion in remote propagated tx case). Guards need to be added to make sure that a tx timeout, doesn't interfere with normal application usage of the entity manager. I think that there are two main cases to be concerned with that involve the afterCompletion sync being invoked in a non-application thread: # TX reaper or other background thread calls afterCompletion while application thread is in (transaction scope) entityManager invocation. # TX reaper or other background thread calls afterCompletion while application thread is not in (transaction scope) entityManager invocation. Extended persistence contexts do not get closed when the JTA transaction that they are joined to are closed (in case anyone is curious). > JPA afterCompletion sync may be called from non-application thread, resolve concurrency concern > ----------------------------------------------------------------------------------------------- > > Key: AS7-6586 > URL: https://issues.jboss.org/browse/AS7-6586 > Project: Application Server 7 > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP), 7.1.3.Final (EAP) > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 8.0.0.Alpha1 > > > For transaction scoped entity managers, the closing the of entity manager is deferred until after the transaction completes. > It is possible that the transaction manager/service may call the Transaction sync from a non-application thread (tx timeout reaper thread or normal completion in remote propagated tx case). Guards need to be added to make sure that a tx timeout, doesn't interfere with normal application usage of the entity manager. > I think that there are two main cases to be concerned with that involve the afterCompletion sync being invoked in a non-application thread: > # TX reaper or other background thread calls afterCompletion while application thread is in (transaction scope) entityManager invocation. > # TX reaper or other background thread calls afterCompletion while application thread is not in (transaction scope) entityManager invocation. > Extended persistence contexts do not get closed when the JTA transaction that they are joined to are closed (in case anyone is curious). > If we are in #1 above, could we delegate the closing of the EntityManager to the in progress EntityManager invocation (to avoid closing the thread unsafe invocation)? Or prevent the background thread from closing the EntityManager until the current EntityManager invocation completes. Or push the requirement up to the top-level EE container (e.g. managed bean, EJB3, web, ...). > The related classes are org.jboss.as.jpa.container.TransactionScopedEntityManager (or AbstractEntityManager) + org.jboss.as.jpa.transaction.TransactionUtil classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6586) JPA afterCompletion sync may be called from non-application thread, resolve concurrency concern

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/AS7-6586?page=com.atlassian.jira.plugin.s... ] Scott Marlow updated AS7-6586: ------------------------------ Description: For transaction scoped entity managers, the closing the of entity manager is deferred until after the transaction completes. It is possible that the transaction manager/service may call the Transaction sync from a non-application thread (tx timeout reaper thread or normal completion in remote propagated tx case). Guards need to be added to make sure that a tx timeout, doesn't interfere with normal application usage of the entity manager. I think that there are two main cases to be concerned with that involve the afterCompletion sync being invoked in a non-application thread: # TX reaper or other background thread calls afterCompletion while application thread is in (transaction scope) entityManager invocation. # TX reaper or other background thread calls afterCompletion while application thread is not in (transaction scope) entityManager invocation. Extended persistence contexts do not get closed when the JTA transaction that they are joined to are closed (in case anyone is curious). was: For transaction scoped entity managers, the closing the of entity manager is deferred until after the transaction completes. It is possible that the transaction manager/service may call the Transaction sync from a non-application thread (tx timeout reaper thread or normal completion in remote propagated tx case). Guards need to be added to make sure that a tx timeout, doesn't interfere with normal application usage of the entity manager. > JPA afterCompletion sync may be called from non-application thread, resolve concurrency concern > ----------------------------------------------------------------------------------------------- > > Key: AS7-6586 > URL: https://issues.jboss.org/browse/AS7-6586 > Project: Application Server 7 > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP), 7.1.3.Final (EAP) > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 8.0.0.Alpha1 > > > For transaction scoped entity managers, the closing the of entity manager is deferred until after the transaction completes. > It is possible that the transaction manager/service may call the Transaction sync from a non-application thread (tx timeout reaper thread or normal completion in remote propagated tx case). Guards need to be added to make sure that a tx timeout, doesn't interfere with normal application usage of the entity manager. > I think that there are two main cases to be concerned with that involve the afterCompletion sync being invoked in a non-application thread: > # TX reaper or other background thread calls afterCompletion while application thread is in (transaction scope) entityManager invocation. > # TX reaper or other background thread calls afterCompletion while application thread is not in (transaction scope) entityManager invocation. > Extended persistence contexts do not get closed when the JTA transaction that they are joined to are closed (in case anyone is curious). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6582) Classloader leaking in JPA module

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/AS7-6582?page=com.atlassian.jira.plugin.s... ] Scott Marlow updated AS7-6582: ------------------------------ Fix Version/s: 8.0.0.Alpha1 > Classloader leaking in JPA module > --------------------------------- > > Key: AS7-6582 > URL: https://issues.jboss.org/browse/AS7-6582 > Project: Application Server 7 > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 7.1.3.Final (EAP) > Environment: Fedora 17, Oracle jdk 7u9 > CentOS 6.3, Oracle jdk 7u11 > Reporter: Brent Douglas > Assignee: Brent Douglas > Fix For: 8.0.0.Alpha1 > > > PersistenceUnitServiceHandler retains references to deployment classes after the service is stopped through SerializableValidatorFactory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-5976) The command :reload does not check the new configuration, and will cause server crashes if that config is broken

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-5976?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration updated AS7-5976: ----------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=901192 > The command :reload does not check the new configuration, and will cause server crashes if that config is broken > ---------------------------------------------------------------------------------------------------------------- > > Key: AS7-5976 > URL: https://issues.jboss.org/browse/AS7-5976 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.2.Final (EAP) > Reporter: Tom Fonteyne > Assignee: Brian Stansberry > Priority: Critical > Fix For: 7.2.0.Alpha1 > > > The command :reload does not check the new configuration, and will cause server crashes if that config is broken -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6588) Implement new java:comp names for EE 7

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/AS7-6588?page=com.atlassian.jira.plugin.s... ] Stuart Douglas reassigned AS7-6588: ----------------------------------- Assignee: Stuart Douglas > Implement new java:comp names for EE 7 > -------------------------------------- > > Key: AS7-6588 > URL: https://issues.jboss.org/browse/AS7-6588 > Project: Application Server 7 > Issue Type: Sub-task > Components: EE, Naming > Reporter: David Lloyd > Assignee: Stuart Douglas > Fix For: 8.0.0.Alpha1 > > > New sections EE.5.16 and EE.5.17 cover JNDI names that have to be bound. > * {{java:comp/InstanceName}} - contains the node name > * {{java:comp/InAppClientContainer}} - contains Boolean.TRUE if running in app client mode > Add more here if found. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBEE-97) See if the jstl dependency on xalan can be refactored out

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/JBEE-97?page=com.atlassian.jira.plugin.sy... ] Jason Greene commented on JBEE-97: ---------------------------------- The jstl library had depdencies on internal SUN jdk classes. This just changes it to depend on real xalan instead of JDK classes. However there is also a bug in xalan that breaks running in any environment that has modular classloading involved (OSGi, EE, etc). We forked to fix it: https://issues.apache.org/jira/browse/XALANJ-2535 Unfortunately they still have yet to merge it. That said IIRC xalan 2.7.1 defaults to the interpreted transformation factory. That one doesnt' have this bug. So it could be possible to switch the dep to standard xalan, and override it in jboss distributions. > See if the jstl dependency on xalan can be refactored out > --------------------------------------------------------- > > Key: JBEE-97 > URL: https://issues.jboss.org/browse/JBEE-97 > Project: JBoss JavaEE Spec APIs > Issue Type: Enhancement > Components: jboss-jstl-api > Affects Versions: JavaEE 6 Spec APIs 3.0.0.Beta1 > Reporter: Paul Gier > Assignee: Jason Greene > Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1 > > > The JSTL api has a dependency on the xalan fork which is only available in the JBoss repository. If this can be refactored out, then the complete set of dependencies will be available in central. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBASMP-37) Add check-style to build

by James Perkins (JIRA)

James Perkins created JBASMP-37: ----------------------------------- Summary: Add check-style to build Key: JBASMP-37 URL: https://issues.jboss.org/browse/JBASMP-37 Project: JBoss AS Maven Plugins Issue Type: Enhancement Reporter: James Perkins Assignee: James Perkins Fix For: 7.4.Final Add check-style to keep consistency in source code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBEE-110) Add relocations from org.jboss.spec.* to non org.jboss.spec artifacts

by Shelly McGowan (JIRA)

[ https://issues.jboss.org/browse/JBEE-110?page=com.atlassian.jira.plugin.s... ] Shelly McGowan commented on JBEE-110: ------------------------------------- @OndrejZizka the list is in the pom: https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/j... > Add relocations from org.jboss.spec.* to non org.jboss.spec artifacts > --------------------------------------------------------------------- > > Key: JBEE-110 > URL: https://issues.jboss.org/browse/JBEE-110 > Project: JBoss JavaEE Spec APIs > Issue Type: Feature Request > Affects Versions: JavaEE 6 Spec APIs 3.0.0.Final > Reporter: Pete Muir > Assignee: Shelly McGowan > Priority: Critical > > For example, we use org.hibernate and javax.enterprise group ids for JPA and CDI. It would be nice if we created stubs with relocations for these under org.jboss.spec so that the new developer can just follow the naming conventions with no exceptions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBEE-113) Add relocations for out of date org.jboss.spec artifact ids

by Paul Gier (JIRA)

[ https://issues.jboss.org/browse/JBEE-113?page=com.atlassian.jira.plugin.s... ] Paul Gier updated JBEE-113: --------------------------- Assignee: Shelly McGowan (was: Paul Gier) > Add relocations for out of date org.jboss.spec artifact ids > ----------------------------------------------------------- > > Key: JBEE-113 > URL: https://issues.jboss.org/browse/JBEE-113 > Project: JBoss JavaEE Spec APIs > Issue Type: Task > Reporter: Pete Muir > Assignee: Shelly McGowan > > This will help indicate to users that they are out of date. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBEE-110) Add relocations from org.jboss.spec.* to non org.jboss.spec artifacts

by Paul Gier (JIRA)

[ https://issues.jboss.org/browse/JBEE-110?page=com.atlassian.jira.plugin.s... ] Paul Gier updated JBEE-110: --------------------------- Assignee: Shelly McGowan (was: Paul Gier) > Add relocations from org.jboss.spec.* to non org.jboss.spec artifacts > --------------------------------------------------------------------- > > Key: JBEE-110 > URL: https://issues.jboss.org/browse/JBEE-110 > Project: JBoss JavaEE Spec APIs > Issue Type: Feature Request > Affects Versions: JavaEE 6 Spec APIs 3.0.0.Final > Reporter: Pete Muir > Assignee: Shelly McGowan > Priority: Critical > > For example, we use org.hibernate and javax.enterprise group ids for JPA and CDI. It would be nice if we created stubs with relocations for these under org.jboss.spec so that the new developer can just follow the naming conventions with no exceptions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2013