[JBoss JIRA] (WFLY-7131) Wildfly 10 Messaging System issue
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-7131?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla updated WFLY-7131:
-----------------------------------
Description:
Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker.
The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis.
http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html
The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messaging are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:-
Let me know if this is good. Also I am attaching the entire standalone-full.xml with this case.
<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
<server name="default">
<security enabled="false"/>
<statistics enabled="true"/>
<security-setting name="#">
<role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
<role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
</security-setting>
<address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
<http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/>
<http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/>
<in-vm-connector name="in-vm" server-id="0"/>
<http-acceptor name="http-acceptor" http-listener="default"/>
<http-acceptor name="http-acceptor-throughput" http-listener="default">
<param name="batch-delay" value="50"/>
<param name="direct-deliver" value="false"/>
</http-acceptor>
<in-vm-acceptor name="in-vm" server-id="0"/>
<jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/>
<jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/>
<jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/>
<jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/>
<jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/>
<jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/>
<jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/>
<connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
<connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/>
<pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/>
</server>
</subsystem>
was:
Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker.
The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis.
http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html
Basically the messaging are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:-
Let me know if this is good. Also I am attaching the entire standalone-full.xml
<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
<server name="default" persistence-enabled="false">
<security enabled="false"/>
<statistics enabled="true"/>
<security-setting name="#">
<role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
<role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
</security-setting>
<address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
<http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/>
<http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/>
<in-vm-connector name="in-vm" server-id="0"/>
<http-acceptor name="http-acceptor" http-listener="default"/>
<http-acceptor name="http-acceptor-throughput" http-listener="default">
<param name="batch-delay" value="50"/>
<param name="direct-deliver" value="false"/>
</http-acceptor>
<in-vm-acceptor name="in-vm" server-id="0"/>
<jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/>
<jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/>
<jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/>
<jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/>
<jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/>
<jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/>
<jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/>
<connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
<connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/>
<pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/>
</server>
</subsystem>
> Wildfly 10 Messaging System issue
> ---------------------------------
>
> Key: WFLY-7131
> URL: https://issues.jboss.org/browse/WFLY-7131
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker.
> The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis.
> http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html
> The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messaging are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:-
> Let me know if this is good. Also I am attaching the entire standalone-full.xml with this case.
> <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
> <server name="default">
> <security enabled="false"/>
> <statistics enabled="true"/>
> <security-setting name="#">
> <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
> <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
> </security-setting>
> <address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
> <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/>
> <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/>
> <in-vm-connector name="in-vm" server-id="0"/>
> <http-acceptor name="http-acceptor" http-listener="default"/>
> <http-acceptor name="http-acceptor-throughput" http-listener="default">
> <param name="batch-delay" value="50"/>
> <param name="direct-deliver" value="false"/>
> </http-acceptor>
> <in-vm-acceptor name="in-vm" server-id="0"/>
> <jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/>
> <jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/>
> <jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/>
> <jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/>
> <jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/>
> <jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/>
> <jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/>
> <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
> <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/>
> <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/>
> </server>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-7131) Wildfly 10 Messaging System issue
by Preeta Kuruvilla (JIRA)
[ https://issues.jboss.org/browse/WFLY-7131?page=com.atlassian.jira.plugin.... ]
Preeta Kuruvilla updated WFLY-7131:
-----------------------------------
Description:
Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker.
The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis.
http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html
Basically the messaging are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:-
Let me know if this is good. Also I am attaching the entire standalone-full.xml
<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
<server name="default" persistence-enabled="false">
<security enabled="false"/>
<statistics enabled="true"/>
<security-setting name="#">
<role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
<role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
</security-setting>
<address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
<http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/>
<http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/>
<in-vm-connector name="in-vm" server-id="0"/>
<http-acceptor name="http-acceptor" http-listener="default"/>
<http-acceptor name="http-acceptor-throughput" http-listener="default">
<param name="batch-delay" value="50"/>
<param name="direct-deliver" value="false"/>
</http-acceptor>
<in-vm-acceptor name="in-vm" server-id="0"/>
<jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/>
<jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/>
<jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/>
<jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/>
<jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/>
<jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/>
<jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/>
<connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
<connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/>
<pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/>
</server>
</subsystem>
was:
Following are the testing scenarios we did and the outcome:-
1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
Jgroups subsystem configuration in domain.xml we have is below:-
<subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
<stack name="udp">
<transport type="UDP" socket-binding="jgroups-udp"/>
<protocol type="PING"/>
<protocol type="MERGE3"/>
<protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
<protocol type="FD_ALL"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS"/>
<protocol type="UFC"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
<protocol type="RSVP"/>
</stack>
<stack name="tcp">
<transport type="TCP" socket-binding="jgroups-tcp"/>
<protocol type="MPING" socket-binding="jgroups-mping"/>
<protocol type="MERGE2"/>
<protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
<protocol type="FD"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
<protocol type="RSVP"/>
</stack>
</subsystem>
> Wildfly 10 Messaging System issue
> ---------------------------------
>
> Key: WFLY-7131
> URL: https://issues.jboss.org/browse/WFLY-7131
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker.
> The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis.
> http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html
> Basically the messaging are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:-
> Let me know if this is good. Also I am attaching the entire standalone-full.xml
> <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
> <server name="default" persistence-enabled="false">
> <security enabled="false"/>
> <statistics enabled="true"/>
> <security-setting name="#">
> <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
> <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
> </security-setting>
> <address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
> <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/>
> <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/>
> <in-vm-connector name="in-vm" server-id="0"/>
> <http-acceptor name="http-acceptor" http-listener="default"/>
> <http-acceptor name="http-acceptor-throughput" http-listener="default">
> <param name="batch-delay" value="50"/>
> <param name="direct-deliver" value="false"/>
> </http-acceptor>
> <in-vm-acceptor name="in-vm" server-id="0"/>
> <jms-queue name="testQueue" entries="queue/test jboss/exported/jms/queue/test"/>
> <jms-queue name="ISEEOutboundQueue" entries="/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/>
> <jms-queue name="ISEEInboundQueue" entries="/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/>
> <jms-queue name="BEEEAuthorizationsQueue" entries="/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/>
> <jms-queue name="BEEERequisitionsQueue" entries="/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/>
> <jms-queue name="BEEEInboundQueue" entries="/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/>
> <jms-topic name="testTopic" entries="topic/test java:jboss/exported/jms/topic/test"/>
> <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
> <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory /RemoteConnectionFactory" connectors="http-connector"/>
> <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/>
> </server>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-7129) Removing XA Datasources via CLI OR DMR does not de-register it from the context without reload.
by shailendra singh (JIRA)
[ https://issues.jboss.org/browse/WFLY-7129?page=com.atlassian.jira.plugin.... ]
shailendra singh edited comment on WFLY-7129 at 9/16/16 2:51 PM:
-----------------------------------------------------------------
possible fix
https://github.com/wildfly/wildfly/pull/9198
was (Author: rhn-support-shsingh):
possible fix
https://issues.jboss.org/browse/WFLY-7129
> Removing XA Datasources via CLI OR DMR does not de-register it from the context without reload.
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-7129
> URL: https://issues.jboss.org/browse/WFLY-7129
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, JCA
> Affects Versions: 10.1.0.Final
> Reporter: shailendra singh
> Assignee: Brian Stansberry
> Priority: Minor
>
> Below is the result of add .. remove ..add operation of XADatasource .
> 1. Add - OK
> {code:java}
> [domain@localhost:9990 /] ./profile=default/subsystem=datasources/xa-data-source=TestXADataSource:add(jndi-name=java\:jboss\/datasources\/oracleXaDatasource,driver-name=oracle-driver.jar)
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => undefined
> }
> {code}
> 2. Remove - OK
> {code:java}
> [domain@localhost:9990 /] ./profile=default/subsystem=datasources/xa-data-source=TestXADataSource:remove()
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => undefined
> }
> {code}
> 3. Add - Error is thrown
> {code:java}
> [domain@localhost:9990 /] ./profile=default/subsystem=datasources/xa-data-source=TestXADataSource:add(jndi-name=java\:jboss\/datasources\/oracleXaDatasource,driver-name=oracle-driver.jar)
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.data-source.TestXADataSource' is already registered in context 'profile=default'."},
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-7131) Wildfly 10 Messaging System issue
by Preeta Kuruvilla (JIRA)
Preeta Kuruvilla created WFLY-7131:
--------------------------------------
Summary: Wildfly 10 Messaging System issue
Key: WFLY-7131
URL: https://issues.jboss.org/browse/WFLY-7131
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 8.2.0.Final
Reporter: Preeta Kuruvilla
Assignee: Jeff Mesnil
Priority: Blocker
Following are the testing scenarios we did and the outcome:-
1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
Jgroups subsystem configuration in domain.xml we have is below:-
<subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
<stack name="udp">
<transport type="UDP" socket-binding="jgroups-udp"/>
<protocol type="PING"/>
<protocol type="MERGE3"/>
<protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
<protocol type="FD_ALL"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS"/>
<protocol type="UFC"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
<protocol type="RSVP"/>
</stack>
<stack name="tcp">
<transport type="TCP" socket-binding="jgroups-tcp"/>
<protocol type="MPING" socket-binding="jgroups-mping"/>
<protocol type="MERGE2"/>
<protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
<protocol type="FD"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
<protocol type="RSVP"/>
</stack>
</subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1805) Intermittent failure in BasicOperationsUnitTestCase.testPathInfo
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1805:
----------------------------------------
Summary: Intermittent failure in BasicOperationsUnitTestCase.testPathInfo
Key: WFCORE-1805
URL: https://issues.jboss.org/browse/WFCORE-1805
Project: WildFly Core
Issue Type: Bug
Components: Domain Management, Test Suite
Affects Versions: 3.0.0.Alpha7
Reporter: Brian Stansberry
Assignee: ehsavoie Hugonnet
Fix For: 3.0.0.Alpha8
This test is failing intermittently. I'm going to @Ignore it.
This one should be a bit higher priority than the typical intermittent test failure as the stuff being tested is pretty new, so there's a higher chance this is a bug in the code instead of just a test issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Scott Marlow edited comment on WFLY-7075 at 9/16/16 2:31 PM:
-------------------------------------------------------------
Any feedback on three recent commits on [https://github.com/scottmarlow/wildfly/tree/WFLY-7075_unsyncXPCExtension]?
[https://github.com/scottmarlow/wildfly/commit/4d3ec0eb2b9ce4034191afa41a8...] addresses https://issues.jboss.org/browse/WFLY-7130 to allow properties to be passed into the @PersistenceContext so users can choose to use either of the two extension hints for the injected persistence context.
[https://github.com/scottmarlow/wildfly/commit/b78c5ae9f1712672480451ce477...] adds the two extension hints for https://issues.jboss.org/browse/WFLY-7075 "wildfly.jpa.allowjoinedunsync=true" can be specified at the @PersistenceContext level to allow a joined UNSYNCHRONIZED pc to be used. "wildfly.jpa.skipmixedsynctypechecking=true" can be specified at the @PersistenceContext level to disable the checking for mixed sync/unsync persistence contexts. We also also allow the same hints to be specified in the persistence.xml as well.
[https://github.com/scottmarlow/wildfly/commit/df62fbbb0583b1834583c8cac29...] addresses the reported defect (now via WFLY-7108), that ExtendedEntityManager.getSynchronizationType() should return the synchronizationType, instead of SynchronizationType.SYNCHRONIZED.
was (Author: smarlow):
Any feedback on three recent commits on [https://github.com/scottmarlow/wildfly/tree/WFLY-7075_unsyncXPCExtension]?
[https://github.com/scottmarlow/wildfly/commit/f137b958d03278b0f67bb30391b...] addresses https://issues.jboss.org/browse/WFLY-7130 to allow properties to be passed into the @PersistenceContext so users can choose to use either of the two extension hints for the injected persistence context.
[https://github.com/scottmarlow/wildfly/commit/484f05a83394a9ba941d12d4a1e...] adds the two extension hints for https://issues.jboss.org/browse/WFLY-7075 "wildfly.jpa.allowjoinedunsync=true" can be specified at the @PersistenceContext level to allow a joined UNSYNCHRONIZED pc to be used. "wildfly.jpa.skipmixedsynctypechecking=true" can be specified at the @PersistenceContext level to disable the checking for mixed sync/unsync persistence contexts. We also also allow the same hints to be specified in the persistence.xml as well.
[https://github.com/scottmarlow/wildfly/commit/df62fbbb0583b1834583c8cac29...] addresses the reported defect (now via WFLY-7108), that ExtendedEntityManager.getSynchronizationType() should return the synchronizationType, instead of SynchronizationType.SYNCHRONIZED.
> proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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)
10 years
[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Scott Marlow edited comment on WFLY-7075 at 9/16/16 2:27 PM:
-------------------------------------------------------------
Any feedback on three recent commits on [https://github.com/scottmarlow/wildfly/tree/WFLY-7075_unsyncXPCExtension]?
[https://github.com/scottmarlow/wildfly/commit/f137b958d03278b0f67bb30391b...] addresses https://issues.jboss.org/browse/WFLY-7130 to allow properties to be passed into the @PersistenceContext so users can choose to use either of the two extension hints for the injected persistence context.
[https://github.com/scottmarlow/wildfly/commit/484f05a83394a9ba941d12d4a1e...] adds the two extension hints for https://issues.jboss.org/browse/WFLY-7075 "wildfly.jpa.allowjoinedunsync=true" can be specified at the @PersistenceContext level to allow a joined UNSYNCHRONIZED pc to be used. "wildfly.jpa.skipmixedsynctypechecking=true" can be specified at the @PersistenceContext level to disable the checking for mixed sync/unsync persistence contexts. We also also allow the same hints to be specified in the persistence.xml as well.
[https://github.com/scottmarlow/wildfly/commit/df62fbbb0583b1834583c8cac29...] addresses the reported defect (now via WFLY-7108), that ExtendedEntityManager.getSynchronizationType() should return the synchronizationType, instead of SynchronizationType.SYNCHRONIZED.
was (Author: smarlow):
Any feedback on three recent commits on [https://github.com/scottmarlow/wildfly/tree/WFLY-7075_unsyncXPCExtension]?
[https://github.com/scottmarlow/wildfly/commit/f137b958d03278b0f67bb30391b...] addresses https://issues.jboss.org/browse/WFLY-7130 to allow properties to be passed into the @PersistenceContext so users can choose to use either of the two extension hints for the injected persistence context.
[https://github.com/scottmarlow/wildfly/commit/484f05a83394a9ba941d12d4a1e...] adds the two extension hints for https://issues.jboss.org/browse/WFLY-7075 "wildfly.jpa.allowjoinedunsync=true" can be specified at the @PersistenceContext level to allow a joined UNSYNCHRONIZED pc to be used. "wildfly.jpa.skipmixedsynctypechecking=true" can be specified at the @PersistenceContext level to disable the checking for mixed sync/unsync persistence contexts. It might be better to also allow the hints to be specified in the persistence.xml as well.
[https://github.com/scottmarlow/wildfly/commit/df62fbbb0583b1834583c8cac29...] addresses the reported defect (now via WFLY-7108), that ExtendedEntityManager.getSynchronizationType() should return the synchronizationType, instead of SynchronizationType.SYNCHRONIZED.
> proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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)
10 years
[JBoss JIRA] (WFLY-7129) Removing XA Datasources via CLI OR DMR does not de-register it from the context without reload.
by shailendra singh (JIRA)
[ https://issues.jboss.org/browse/WFLY-7129?page=com.atlassian.jira.plugin.... ]
shailendra singh commented on WFLY-7129:
----------------------------------------
possible fix
https://issues.jboss.org/browse/WFLY-7129
> Removing XA Datasources via CLI OR DMR does not de-register it from the context without reload.
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-7129
> URL: https://issues.jboss.org/browse/WFLY-7129
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, JCA
> Affects Versions: 10.1.0.Final
> Reporter: shailendra singh
> Assignee: Brian Stansberry
> Priority: Minor
>
> Below is the result of add .. remove ..add operation of XADatasource .
> 1. Add - OK
> {code:java}
> [domain@localhost:9990 /] ./profile=default/subsystem=datasources/xa-data-source=TestXADataSource:add(jndi-name=java\:jboss\/datasources\/oracleXaDatasource,driver-name=oracle-driver.jar)
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => undefined
> }
> {code}
> 2. Remove - OK
> {code:java}
> [domain@localhost:9990 /] ./profile=default/subsystem=datasources/xa-data-source=TestXADataSource:remove()
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => undefined
> }
> {code}
> 3. Add - Error is thrown
> {code:java}
> [domain@localhost:9990 /] ./profile=default/subsystem=datasources/xa-data-source=TestXADataSource:add(jndi-name=java\:jboss\/datasources\/oracleXaDatasource,driver-name=oracle-driver.jar)
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.data-source.TestXADataSource' is already registered in context 'profile=default'."},
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-7075:
------------------------------------
Any feedback on three recent commits on [https://github.com/scottmarlow/wildfly/tree/WFLY-7075_unsyncXPCExtension]?
[https://github.com/scottmarlow/wildfly/commit/f137b958d03278b0f67bb30391b...] addresses https://issues.jboss.org/browse/WFLY-7130 to allow properties to be passed into the @PersistenceContext so users can choose to use either of the two extension hints for the injected persistence context.
[https://github.com/scottmarlow/wildfly/commit/484f05a83394a9ba941d12d4a1e...] adds the two extension hints for https://issues.jboss.org/browse/WFLY-7075 "wildfly.jpa.allowjoinedunsync=true" can be specified at the @PersistenceContext level to allow a joined UNSYNCHRONIZED pc to be used. "wildfly.jpa.skipmixedsynctypechecking=true" can be specified at the @PersistenceContext level to disable the checking for mixed sync/unsync persistence contexts. It might be better to also allow the hints to be specified in the persistence.xml as well.
[https://github.com/scottmarlow/wildfly/commit/df62fbbb0583b1834583c8cac29...] addresses the reported defect (now via WFLY-7108), that ExtendedEntityManager.getSynchronizationType() should return the synchronizationType, instead of SynchronizationType.SYNCHRONIZED.
> proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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)
10 years
[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-7075:
-------------------------------
Summary: proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX (was: proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped)
> proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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)
10 years