[jboss-jira] [JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
Viacheslav Astapkovich (JIRA)
issues at jboss.org
Mon Sep 5 11:52:00 EDT 2016
[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288791#comment-13288791 ]
Viacheslav Astapkovich edited comment on WFLY-6127 at 9/5/16 11:51 AM:
-----------------------------------------------------------------------
*The obtained defect:*
A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
The Method getSynchronizationType of ExtendedEntityManager class ALWAYS returns SYNCHRONIZED type of synchronization.
*FIX:*
We created a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e69c562c40
Corrections: The method getSynchronizationType returns declared synchronization type.
*Effect:*
We use our own realization of Martin Fowler’s pattern "Unit of Work". We initialize Unsynchronized Extended Persistence Context and our realization controls the synchronization with transaction.
Our Beans can be controlled by UnitOfWork, as well as be used as a part of WebService.
This requires the declaration of synchronized persistence context.
We catch IllegalStateException after we have fixed the defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we declare synchronized persistence context in our beans.
However, our UnitOfWork realization controls synchronization of persistence context and we can synchronize context before the synchronization type check.
*Our actions:*
We had to add the possibility to check synchronization type in the testForMixedSynchronizationTypes method of TransactionScopedEntityManager class by isJoinToTransaction method (i.e. the actual type of synchronization).
This ability is realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property is set to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. The system operates as usual if this property is not defined or set to false.
*Commentary:*
Though our actions deviate from JPA SPEC, we have a valid reason for acting this way:
- A question arose in the development process of the JPA specification : "Should we relax this if the PC has been joined to the transaction?".
Unfortunately, no feedback was given and Linda DeMichiel decided to keep it as it was
( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/message/5 )
- We found a JIRA task https://java.net/jira/browse/JPA_SPEC-6 . And it was also closed too: "No feedback in favor of changing current approach"
was (Author: veselroger):
*The obtained defect:*
A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
The Method getSynchronizationType of ExtendedEntityManager class ALWAYS returns SYNCHRONIZED type of synchronization.
*FIX:*
We created a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e69c562c40
Corrections: The method getSynchronizationType returns declared synchronization type.
*Effect:*
We use our own realization of Martin Fowler’s pattern "Unit of Work". We initialize Unsynchronized Extended Persistence Context and our realization controls the synchronization with transaction.
Our Beans can be controlled by UnitOfWork, as well as be used as a part of WebService.
This requires the declaration of synchronized persistence context.
We catch IllegalStateException after we have fixed the defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we declare synchronized persistence context in our beans.
However, our UnitOfWork realization controls synchronization of persistence context and we can synchronize context before the synchronization type check.
*Our actions:*
We had to add the possibility to check synchronization type in the testForMixedSynchronizationTypes method of TransactionScopedEntityManager class by isJoinToTransaction method (i.e. the actual type of synchronization).
This ability is realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property is set to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. The system operates as usual if this property is not defined or set to false.
*Commentary:*
Though our actions deviate from JPA SPEC, we have a valid reason for acting this way:
- A question arose in the development process of the JPA specification : "Should we relax this if the PC has been joined to the transaction?".
Unfortunately, no feedback was given and Linda DeMichiel decided to keep it as it was
( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/message/5 )
- We also found a JIRA task https://java.net/jira/browse/JPA_SPEC-6 . And it was closed too because "No feedback in favor of changing current approach"
> Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6127
> URL: https://issues.jboss.org/browse/WFLY-6127
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 9.0.2.Final
> Reporter: Mazen Mahmoud
> Assignee: Scott Marlow
> Priority: Blocker
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
> Attachments: server-log.txt
>
>
> SPEC: If a component is called and the JTA transaction is propagated into that component:
> If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED
> associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container
> We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED)
> stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED)
> SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED):
> PC is propagated from SFB1 to SFB2 without any exception.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
More information about the jboss-jira
mailing list