[JBoss JIRA] (DROOLS-1286) GDT editor: unable to specify Literal value or Template key for domain objects as Condition BRL fragment
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1286?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1286:
--------------------------------
Reporter: Michael Anstis (was: Hiroko Miura)
> GDT editor: unable to specify Literal value or Template key for domain objects as Condition BRL fragment
> ---------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1286
> URL: https://issues.jboss.org/browse/DROOLS-1286
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 6.4.0.Final
> Reporter: Michael Anstis
> Assignee: Mario Fusco
> Labels: support
> Attachments: Screen_Shot.png
>
>
> Guided Decision Table: When adding a Condition BRL fragment it is not possible to enter a template key or value for an attribute on a domain object.
> In the attached screen shot, when clicking pencil icon, nothing appear.
> This is confirmed by both FireFox anc Chrome.
> At that time, the following error is shown in browser's console.
> [Chrome]
> 12:44:40 SEVERE [LogConfiguration] Exception caught: (TypeError) : Cannot read property 'indexOf' of null
>
> [FireFox]
> 00:10:46 SEVERE [LogConfiguration] Exception caught: (TypeError) : b.indexOf is null
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1286) GDT editor: unable to specify Literal value or Template key for domain objects as Condition BRL fragment
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1286?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1286:
--------------------------------
Reporter: Hiroko Miura (was: Michael Anstis)
> GDT editor: unable to specify Literal value or Template key for domain objects as Condition BRL fragment
> ---------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1286
> URL: https://issues.jboss.org/browse/DROOLS-1286
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 6.4.0.Final
> Reporter: Hiroko Miura
> Assignee: Mario Fusco
> Labels: support
> Attachments: Screen_Shot.png
>
>
> Guided Decision Table: When adding a Condition BRL fragment it is not possible to enter a template key or value for an attribute on a domain object.
> In the attached screen shot, when clicking pencil icon, nothing appear.
> This is confirmed by both FireFox anc Chrome.
> At that time, the following error is shown in browser's console.
> [Chrome]
> 12:44:40 SEVERE [LogConfiguration] Exception caught: (TypeError) : Cannot read property 'indexOf' of null
>
> [FireFox]
> 00:10:46 SEVERE [LogConfiguration] Exception caught: (TypeError) : b.indexOf is null
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2092:
--------------------------------
A simple way to fix this would be to take the first members (coords) of all subviews and have them run the merge. In the Sept 12 example, this would be the set \{A,B,C\}. However, this would mean that _participants_ (not _coordinators_) would be able to run the show, ie. install new views, which is something that JGroups hasn't liked so far.
I need to think about whether anyone being able to install new views is a security risk...
Also, MERGE3 would have everyone run the ConsistencyChecker task, and not just the coordinators.
Perhaps this additional behavior can be enabled via an attribute (in GMS and MERGE3). By default, it would be true, so participants are allowed to run merges and install views. If this turns out to cause no problems over a couple of releases, we can remove the flag again...
> MERGE3: merge never happens
> ---------------------------
>
> Key: JGRP-2092
> URL: https://issues.jboss.org/browse/JGRP-2092
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
> Attachments: jgroups.txt
>
>
> (Reported by Neal Dillman)
> In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this.
> {noformat}
> Host A view: B, X, Y, Z, A (where B should be coordinator)
> Host B view: C, Q, R, S, B (where C should be coordinator)
> Host C view: A, M, N, O, C (where A should be coordinator)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1286) GDT editor: unable to specify Literal value or Template key for domain objects as Condition BRL fragment
by Hiroko Miura (JIRA)
Hiroko Miura created DROOLS-1286:
------------------------------------
Summary: GDT editor: unable to specify Literal value or Template key for domain objects as Condition BRL fragment
Key: DROOLS-1286
URL: https://issues.jboss.org/browse/DROOLS-1286
Project: Drools
Issue Type: Bug
Components: decision tables
Affects Versions: 6.4.0.Final
Reporter: Hiroko Miura
Assignee: Mario Fusco
Attachments: Screen_Shot.png
Guided Decision Table: When adding a Condition BRL fragment it is not possible to enter a template key or value for an attribute on a domain object.
In the attached screen shot, when clicking pencil icon, nothing appear.
This is confirmed by both FireFox anc Chrome.
At that time, the following error is shown in browser's console.
[Chrome]
12:44:40 SEVERE [LogConfiguration] Exception caught: (TypeError) : Cannot read property 'indexOf' of null
[FireFox]
00:10:46 SEVERE [LogConfiguration] Exception caught: (TypeError) : b.indexOf is null
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7075) proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-7075:
-------------------------------
Description:
As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
*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 class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
*FIX:*
We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
_Changes_: The method getSynchronizationType returns declared synchronization type.
[WFLY-7108] is now the tracking jira for the fix.
*Consequences:*
We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
It requires a declaration of synchronize persistence context.
We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.
However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.
*Our actions:*
We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
_Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
*Example for reproduction:*
I modified quickstart example: [^kitchensink-ear.rar]
MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
MemberRepository also perform join Transaction.
Questions from [~smarlow]:
- whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
We decided to use Container-managed EntityManager, because
- Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
- The container makes our job
We want to use the existing mechanism
*In Addition:*
Formally, this is out of JPA SPEC, but we have the following reasons:
- In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
- We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"
was:
As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
*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 class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
*FIX:*
We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
_Changes_: The method getSynchronizationType returns declared synchronization type.
*Consequences:*
We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
It requires a declaration of synchronize persistence context.
We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.
However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.
*Our actions:*
We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
_Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
*Example for reproduction:*
I modified quickstart example: [^kitchensink-ear.rar]
MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
MemberRepository also perform join Transaction.
Questions from [~smarlow]:
- whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
We decided to use Container-managed EntityManager, because
- Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
- The container makes our job
We want to use the existing mechanism
*In Addition:*
Formally, this is out of JPA SPEC, but we have the following reasons:
- In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
- We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"
> proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7075
> URL: https://issues.jboss.org/browse/WFLY-7075
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Environment: *AppServer:* WildFly 10.1.0.Final
> *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar
> Reporter: Viacheslav Astapkovich
> Assignee: Scott Marlow
> Attachments: kitchensink-ear.rar
>
>
> As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
>
> *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 class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
> *FIX:*
> We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
> Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
> _Changes_: The method getSynchronizationType returns declared synchronization type.
> [WFLY-7108] is now the tracking jira for the fix.
> *Consequences:*
> We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
> Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
> It requires a declaration of synchronize persistence context.
> We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.
> However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.
> *Our actions:*
> We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
> This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
> _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
> *Example for reproduction:*
> I modified quickstart example: [^kitchensink-ear.rar]
> MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
> MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
> MemberRepository also perform join Transaction.
> Questions from [~smarlow]:
> - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
> We decided to use Container-managed EntityManager, because
> - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
> - The container makes our job
> We want to use the existing mechanism
> *In Addition:*
> Formally, this is out of JPA SPEC, but we have the following reasons:
> - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
> But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
> ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
> - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7108) UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7108?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-7108:
-------------------------------
Description:
As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
*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 class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
*FIX:*
We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
_Changes_: The method getSynchronizationType returns declared synchronization type.
was:
As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
*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 class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
*FIX:*
We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
_Changes_: The method getSynchronizationType returns declared synchronization type.
*Consequences:*
We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
It requires a declaration of synchronize persistence context.
We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.
However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.
*Our actions:*
We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
_Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
*Example for reproduction:*
I modified quickstart example: [^kitchensink-ear.rar]
MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
MemberRepository also perform join Transaction.
Questions from [~smarlow]:
- whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
We decided to use Container-managed EntityManager, because
- Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
- The container makes our job
We want to use the existing mechanism
*In Addition:*
Formally, this is out of JPA SPEC, but we have the following reasons:
- In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
- We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"
> UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7108
> URL: https://issues.jboss.org/browse/WFLY-7108
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Environment: *AppServer:* WildFly 10.1.0.Final
> *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar
> Reporter: Scott Marlow
> Assignee: Scott Marlow
>
> As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
>
> *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 class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
> *FIX:*
> We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
> Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
> _Changes_: The method getSynchronizationType returns declared synchronization type.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7108) UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7108?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-7108:
------------------------------------
[~veselroger] is the reporter of this jira, I cloned it from WFLY-7075.
> UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7108
> URL: https://issues.jboss.org/browse/WFLY-7108
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Environment: *AppServer:* WildFly 10.1.0.Final
> *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar
> Reporter: Scott Marlow
> Assignee: Scott Marlow
>
> As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
>
> *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 class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
> *FIX:*
> We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
> Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
> _Changes_: The method getSynchronizationType returns declared synchronization type.
> *Consequences:*
> We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
> Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
> It requires a declaration of synchronize persistence context.
> We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.
> However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.
> *Our actions:*
> We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
> This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
> _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
> *Example for reproduction:*
> I modified quickstart example: [^kitchensink-ear.rar]
> MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
> MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
> MemberRepository also perform join Transaction.
> Questions from [~smarlow]:
> - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
> We decided to use Container-managed EntityManager, because
> - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
> - The container makes our job
> We want to use the existing mechanism
> *In Addition:*
> Formally, this is out of JPA SPEC, but we have the following reasons:
> - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
> But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
> ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
> - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7108) UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7108?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-7108:
------------------------------------
WFLY-7075 adds an extension for disabling the test for whether the unsynchronized persistence context is available when a synchronized (or JTA joined) persistence context is needed.
WFLY-7108 addresses the identified bug mentioned in WFLY-7075. We will fix the identified bug via a separate jira in case we decide to back port the bug fix but not the extension. At this point, I think they are both useful but still prefer the separation.
> UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7108
> URL: https://issues.jboss.org/browse/WFLY-7108
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Environment: *AppServer:* WildFly 10.1.0.Final
> *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar
> Reporter: Scott Marlow
> Assignee: Scott Marlow
>
> As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
>
> *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 class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
> *FIX:*
> We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
> Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
> _Changes_: The method getSynchronizationType returns declared synchronization type.
> *Consequences:*
> We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
> Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
> It requires a declaration of synchronize persistence context.
> We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.
> However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.
> *Our actions:*
> We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
> This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
> _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
> *Example for reproduction:*
> I modified quickstart example: [^kitchensink-ear.rar]
> MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
> MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
> MemberRepository also perform join Transaction.
> Questions from [~smarlow]:
> - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
> We decided to use Container-managed EntityManager, because
> - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
> - The container makes our job
> We want to use the existing mechanism
> *In Addition:*
> Formally, this is out of JPA SPEC, but we have the following reasons:
> - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
> But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
> ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
> - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months