[JBoss JIRA] (JBTM-846) Allow multiple transaction managers with different configurations to operate in a single JVM
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-846?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson commented on JBTM-846:
------------------------------------
Lets go for the "refocus this solely on the WF use case"
> Allow multiple transaction managers with different configurations to operate in a single JVM
> --------------------------------------------------------------------------------------------
>
> Key: JBTM-846
> URL: https://issues.jboss.org/browse/JBTM-846
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JTA, JTS, Recovery, Transaction Core, XTS
> Reporter: Tom Jenkinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.Final
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> This will require removal of much of the static configuration state such as StateManager references to ObjectStore
> The use case provided for this is to run a separate transaction/recovery manager for Transactional MSC to the one that WildFly is using for its (JTA/JTS) EJB container.
--
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
12 years, 9 months
[JBoss JIRA] (JBTM-1728) Use a global environment variable in CI for version numbers of Narayana and WildFly
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-1728?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-1728:
----------------------------------------
We build the AS as part of the CI run so we should be using that version rather than some random version that gets put into WILDFLY_MASTER_VERSION.
Also the value in WILDFLY_MASTER_VERSION should be consistent with the value that JBOSS_HOME gets set to.
> Use a global environment variable in CI for version numbers of Narayana and WildFly
> -----------------------------------------------------------------------------------
>
> Key: JBTM-1728
> URL: https://issues.jboss.org/browse/JBTM-1728
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Build System, Testing
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M4
>
> Original Estimate: 2 hours
> Time Spent: 55 minutes
> Remaining Estimate: 0 minutes
>
> We have "8.0.0.Alpha2-SNAPSHOT" scattered over many jobs. This is a pain to change every time we have a new release of Wildfly. We also have the same issue with jboss-as-7.2.0.Final.
> We should use global env variables instead. See the following for how to do it. Notice that I have already added one for Narayana.
> http://172.17.131.2/configure
> Call the variables:
> WILDFLY_MASTER_VERSION=8.0.0.Alpha2-SNAPSHOT
> JBOSS_7_2_VERSION=7.2.0.Final
> Ask paul to update the sanity check job before this is done. This will blacklist the usage of hardcoded wildfly/jboss version numbers. It will make it a lot easier to find all the places it is used.
--
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
12 years, 9 months
[JBoss JIRA] (JBTM-846) Allow multiple transaction managers with different configurations to operate in a single JVM
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-846?page=com.atlassian.jira.plugin.s... ]
Mark Little commented on JBTM-846:
----------------------------------
Allowing multiple TMs in the same JVM is a generic statement and although WF needs this, there may be other users who want it for different reasons. I think we should either define this as a generic problem which we can try to solve for other use cases (do we know them all?) or we should refocus this solely on the WF use case and then come back to a more general requirement if/when it comes back up.
> Allow multiple transaction managers with different configurations to operate in a single JVM
> --------------------------------------------------------------------------------------------
>
> Key: JBTM-846
> URL: https://issues.jboss.org/browse/JBTM-846
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JTA, JTS, Recovery, Transaction Core, XTS
> Reporter: Tom Jenkinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.Final
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> This will require removal of much of the static configuration state such as StateManager references to ObjectStore
> The use case provided for this is to run a separate transaction/recovery manager for Transactional MSC to the one that WildFly is using for its (JTA/JTS) EJB container.
--
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
12 years, 9 months
[JBoss JIRA] (JBTM-1829) Recovery creator service fails to start in JacORBGenericRecoveryCreatorUnitTest
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1829?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson edited comment on JBTM-1829 at 7/12/13 9:02 AM:
--------------------------------------------------------------
I have pushed https://github.com/jbosstm/narayana/commit/67caccedaf6e4098a1d1ed68f661d0... which splits the test in two. It is now working on CI, thanks again for the suggestion
was (Author: tomjenkinson):
I have pushed https://github.com/jbosstm/narayana/commit/67caccedaf6e4098a1d1ed68f661d0... which splits the test in two. It seems to be working on CI for the current build thanks again for the suggestion
> Recovery creator service fails to start in JacORBGenericRecoveryCreatorUnitTest
> -------------------------------------------------------------------------------
>
> Key: JBTM-1829
> URL: https://issues.jboss.org/browse/JBTM-1829
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JTS
> Reporter: Gytis Trikleris
> Assignee: Tom Jenkinson
> Priority: Minor
> Fix For: 5.0.0.M4
>
>
> http://172.17.131.2/view/Narayana+BlackTie/job/narayana/177/TESTS=MAIN,jd...
> http://172.17.131.2/view/Narayana+BlackTie/job/narayana-codeCoverage/50
> {code}
> Emptying /home/hudson/workspace/narayana/TESTS/MAIN/jdk/jdk7.latest/label/linux/ArjunaJTS/jts/target/test-classes/ObjectStore
> 1 [main] WARN jacorb.config - jacorb.home unset! Will use '.'
> 1 [main] WARN jacorb.config - File ./jacorb.properties for configuration jacorb not found
> 2 [main] WARN jacorb.config - no properties found for configuration jacorb
> 5 [main] INFO jacorb.orb.print_version -
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> JacORB V 2.3.1 (JBoss patch01), www.jacorb.org
> (C) The JacORB project 29-Jul-2009
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 40 [main] INFO jacorb.orb - Property "jacorb.hashtable_class" is set to: java.util.HashMap
> Jul 07, 2013 5:55:53 PM com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit initORBandOA
> INFO: ARJUNA022087: RecoveryServer using existing ORB
> 201 [main] WARN jacorb.config - jacorb.home unset! Will use '.'
> 201 [main] WARN jacorb.config - File ./jacorb.properties for configuration jacorb not found
> 202 [main] WARN jacorb.config - no properties found for configuration jacorb
> 202 [main] INFO jacorb.orb.singleton - created ORBSingleton
> 313 [main] INFO jacorb.poa - oid:
> 00 17 4C 48 03 47 41 4C 02 05 32 ..LH.GAL..2
> object is activated
> 314 [main] INFO jacorb.poa - Using server ID (4426315968) for transient POA
> Jul 07, 2013 5:55:53 PM com.arjuna.ats.internal.jts.recovery.recoverycoordinators.GenericRecoveryCreator create
> WARN: ARJUNA022156: GenericRecoveryCreator: Missing params to create
> 318 [Thread-3] INFO jacorb.orb - ORB run
> 321 [POADestructor] INFO jacorb.poa - POA RcvCo-RecCoService_jaimerecovery_coordinator destroyed
> 322 [POADestructor] INFO jacorb.poa - POA RootPOA destroyed
> 322 [main] INFO jacorb.orb - prepare ORB for shutdown...
> 322 [main] INFO jacorb.orb - ORB going down...
> 323 [ServerSocketListener] INFO jacorb.orb.iiop - Listener exited
> 323 [main] INFO jacorb.orb - ORB shutdown complete
> Emptying /home/hudson/workspace/narayana/TESTS/MAIN/jdk/jdk7.latest/label/linux/ArjunaJTS/jts/target/test-classes/ObjectStore
> Emptying /home/hudson/workspace/narayana/TESTS/MAIN/jdk/jdk7.latest/label/linux/ArjunaJTS/jts/target/test-classes/ObjectStore
> 328 [main] WARN jacorb.config - jacorb.home unset! Will use '.'
> 328 [main] WARN jacorb.config - File ./jacorb.properties for configuration jacorb not found
> 329 [main] WARN jacorb.config - no properties found for configuration jacorb
> 329 [main] INFO jacorb.orb.print_version -
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> JacORB V 2.3.1 (JBoss patch01), www.jacorb.org
> (C) The JacORB project 29-Jul-2009
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 329 [main] INFO jacorb.orb - Property "jacorb.hashtable_class" is set to: java.util.HashMap
> 330 [Thread-3] INFO jacorb.orb - ORB run, exit
> Jul 07, 2013 5:55:53 PM com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit initORBandOA
> INFO: ARJUNA022087: RecoveryServer using existing ORB
> 333 [POADestructor] INFO jacorb.poa - POA RcvCo-RecCoService_jaimerecovery_coordinator destroyed
> 333 [POADestructor] INFO jacorb.poa - POA RootPOA destroyed
> 333 [Thread-3] INFO jacorb.orb - prepare ORB for shutdown...
> 333 [Thread-3] INFO jacorb.orb - ORB going down...
> 333 [Thread-3] INFO jacorb.orb - ORB shutdown complete
> 334 [ServerSocketListener] INFO jacorb.orb.iiop - Listener exited
> Jul 07, 2013 5:55:53 PM com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit startRCservice
> WARN: ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service
> org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed vmcid: 0x0 minor code: 0 completed: No
> at org.jacorb.poa.POA.checkDestructionApparent(Unknown Source)
> at org.jacorb.poa.POA.the_POAManager(Unknown Source)
> at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:225)
> at com.hp.mwtests.ts.jts.recovery.JacORBGenericRecoveryCreatorUnitTest.testSuccess(JacORBGenericRecoveryCreatorUnitTest.java:95)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Jul 07, 2013 5:55:53 PM com.arjuna.orbportability.RootOA objectIsReady
> WARN: ARJUNA021004: objectIsReady - invalid POA: rootPOA
> Jul 07, 2013 5:55:53 PM com.arjuna.ats.arjuna.recovery.TransactionStatusManager addService
> INFO: ARJUNA012163: Starting service com.arjuna.ats.arjuna.recovery.ActionStatusService on port 48098
> Jul 07, 2013 5:55:53 PM com.arjuna.ats.internal.arjuna.recovery.TransactionStatusManagerItem <init>
> INFO: ARJUNA012337: TransactionStatusManagerItem host: 127.0.0.1 port: 48098
> Jul 07, 2013 5:55:53 PM com.arjuna.ats.arjuna.recovery.TransactionStatusManager start
> INFO: ARJUNA012170: TransactionStatusManager started on port 48098 and host 127.0.0.1 with service com.arjuna.ats.arjuna.recovery.ActionStatusService
> Jul 07, 2013 5:55:53 PM com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCManager makeRC
> WARN: ARJUNA022077: RCManager.makeRC did not make rcvco reference
> org.omg.CORBA.BAD_INV_ORDER: vmcid: 0x0 minor code: 4 completed: No
> at org.jacorb.orb.ORB.work_pending(Unknown Source)
> at org.jacorb.orb.ORB.perform_work(Unknown Source)
> at org.jacorb.orb.ORB.string_to_object(Unknown Source)
> at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCManager.makeRC(JacOrbRCManager.java:102)
> at com.arjuna.ats.internal.jts.recovery.recoverycoordinators.GenericRecoveryCreator.create(GenericRecoveryCreator.java:121)
> at com.hp.mwtests.ts.jts.recovery.JacORBGenericRecoveryCreatorUnitTest.testSuccess(JacORBGenericRecoveryCreatorUnitTest.java:111)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Emptying /home/hudson/workspace/narayana/TESTS/MAIN/jdk/jdk7.latest/label/linux/ArjunaJTS/jts/target/test-classes/ObjectStore
> Jul 07, 2013 5:55:53 PM com.arjuna.ats.internal.arjuna.objectstore.ShadowingStore remove_state
> WARN: ARJUNA012284: ShadowingStore::remove_state() - access problems on 0:ffffac118321:8b3f:51d99d99:3 and /Recovery/TransactionStatusManager
> Jul 07, 2013 5:55:53 PM com.arjuna.ats.internal.arjuna.objectstore.ShadowingStore remove_state
> WARN: ARJUNA012265: ShadowingStore::remove_state() - state 0:ffffac118321:8b3f:51d99d99:3 does not exist for type /Recovery/TransactionStatusManager
> {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
12 years, 9 months
[JBoss JIRA] (JBTM-846) Allow multiple transaction managers with different configurations to operate in a single JVM
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-846?page=com.atlassian.jira.plugin.s... ]
Mark Little commented on JBTM-846:
----------------------------------
Why would we need to recovery managers? As long as the transactions are unique and things like the nodename are shared by recovery, it should be possible to have one instance.
> Allow multiple transaction managers with different configurations to operate in a single JVM
> --------------------------------------------------------------------------------------------
>
> Key: JBTM-846
> URL: https://issues.jboss.org/browse/JBTM-846
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JTA, JTS, Recovery, Transaction Core, XTS
> Reporter: Tom Jenkinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.Final
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> This will require removal of much of the static configuration state such as StateManager references to ObjectStore
> The use case provided for this is to run a separate transaction/recovery manager for Transactional MSC to the one that WildFly is using for its (JTA/JTS) EJB container.
--
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
12 years, 9 months
[JBoss JIRA] (JBTM-846) Allow multiple transaction managers with different configurations to operate in a single JVM
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-846?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson edited comment on JBTM-846 at 7/12/13 8:31 AM:
-------------------------------------------------------------
To address Davids requirement we need to support 1xArjunaCore (for the MSC) and 1xArjunaJTA||ArjunaJTS (for the EJB container). The problem is the recovery manager, are we expecting to launch two of those in the same VM? I presume we have to in order to cleanly separate the MSC from the EJB container (e.g. different object stores)
was (Author: tomjenkinson):
To address Davids requirement we need to support 1xArjunaCore (for the MSC) and 1xArjunaJTA (for the EJB container). The problem is the recovery manager, are we expecting to launch two of those in the same VM? I presume we have to in order to cleanly separate the MSC from the EJB container (e.g. different object stores)
> Allow multiple transaction managers with different configurations to operate in a single JVM
> --------------------------------------------------------------------------------------------
>
> Key: JBTM-846
> URL: https://issues.jboss.org/browse/JBTM-846
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JTA, JTS, Recovery, Transaction Core, XTS
> Reporter: Tom Jenkinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.Final
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> This will require removal of much of the static configuration state such as StateManager references to ObjectStore
> The use case provided for this is to run a separate transaction/recovery manager for Transactional MSC to the one that WildFly is using for its (JTA/JTS) EJB container.
--
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
12 years, 9 months
[JBoss JIRA] (JBTM-846) Allow multiple transaction managers with different configurations to operate in a single JVM
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-846?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson updated JBTM-846:
-------------------------------
Description:
This will require removal of much of the static configuration state such as StateManager references to ObjectStore
The use case provided for this is to run a separate transaction/recovery manager for Transactional MSC to the one that WildFly is using for its (JTA/JTS) EJB container.
was:This will require removal of much of the static configuration state such as StateManager references to ObjectStore
> Allow multiple transaction managers with different configurations to operate in a single JVM
> --------------------------------------------------------------------------------------------
>
> Key: JBTM-846
> URL: https://issues.jboss.org/browse/JBTM-846
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JTA, JTS, Recovery, Transaction Core, XTS
> Reporter: Tom Jenkinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.Final
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> This will require removal of much of the static configuration state such as StateManager references to ObjectStore
> The use case provided for this is to run a separate transaction/recovery manager for Transactional MSC to the one that WildFly is using for its (JTA/JTS) EJB container.
--
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
12 years, 9 months
[JBoss JIRA] (JBTM-846) Allow multiple transaction managers with different configurations to operate in a single JVM
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-846?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson commented on JBTM-846:
------------------------------------
To address Davids requirement we need to support 1xArjunaCore (for the MSC) and 1xArjunaJTA (for the EJB container). The problem is the recovery manager, are we expecting to launch two of those in the same VM? I presume we have to in order to cleanly separate the MSC from the EJB container (e.g. different object stores)
> Allow multiple transaction managers with different configurations to operate in a single JVM
> --------------------------------------------------------------------------------------------
>
> Key: JBTM-846
> URL: https://issues.jboss.org/browse/JBTM-846
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JTA, JTS, Recovery, Transaction Core, XTS
> Reporter: Tom Jenkinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.Final
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> This will require removal of much of the static configuration state such as StateManager references to ObjectStore
--
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
12 years, 9 months
[JBoss JIRA] (JBTM-1568) Install the StompConnect component of BlackTie as an WildFly subsystem module
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1568?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1568:
-------------------------------------
Hi Amos,
The problem is that the hq stomp connector does not support XA.
Tom
> Install the StompConnect component of BlackTie as an WildFly subsystem module
> -----------------------------------------------------------------------------
>
> Key: JBTM-1568
> URL: https://issues.jboss.org/browse/JBTM-1568
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Reporter: Tom Jenkinson
> Assignee: Amos Feng
> Fix For: 5.0.0.Final
>
> Original Estimate: 2 weeks
> Time Spent: 1 week, 1 day
> Remaining Estimate: 4 days
>
> Apparently there is a way to deploy a war as a module coming soon, wait till this is available possibly. Though, in the meantime, you could merge the stompconnect ear and blacktie-admin-servers ear into a single ear.
--
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
12 years, 9 months
[JBoss JIRA] (JBTM-846) Allow multiple transaction managers with different configurations to operate in a single JVM
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-846?page=com.atlassian.jira.plugin.s... ]
Mark Little commented on JBTM-846:
----------------------------------
Thanks. I suggest that we do this in stages anyway, starting with ArjunaCore. If there are requirements for JTA, JTS, XTS, REST-TX then we should address them in subsequent releases. And technically we have to start with ArjunaCore anyway ;-)
> Allow multiple transaction managers with different configurations to operate in a single JVM
> --------------------------------------------------------------------------------------------
>
> Key: JBTM-846
> URL: https://issues.jboss.org/browse/JBTM-846
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JTA, JTS, Recovery, Transaction Core, XTS
> Reporter: Tom Jenkinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.Final
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> This will require removal of much of the static configuration state such as StateManager references to ObjectStore
--
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
12 years, 9 months