March 2017 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2850) Call xa_end on duplicate XAResource as per JTA 1.2 specification

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2850: -------------------------------- Fix Version/s: 5.5.5.Final (was: 5.next) > Call xa_end on duplicate XAResource as per JTA 1.2 specification > ---------------------------------------------------------------- > > Key: JBTM-2850 > URL: https://issues.jboss.org/browse/JBTM-2850 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.5.5.Final > > > JTA 1.2 changed requirement: > "A transaction manager is, however, required to implicitly ensure the association of any associated XAResource is ended, via the appropriate XAResource.end call, immediately prior to completion;" > The change is that it no longer is confined to any associated ** resource **, but now specifies any associated ** XAResource ** > What is happening at the moment for two difference instance of an XAR but where isSameRM is true: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit > Post https://java.net/jira/browse/JTA_SPEC-3 this should be: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > DuplicateResource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2850) Call xa_end on duplicate XAResource as per JTA 1.2 specification

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2850: -------------------------------- Fix Version/s: 5.next (was: 5.5.4.Final) > Call xa_end on duplicate XAResource as per JTA 1.2 specification > ---------------------------------------------------------------- > > Key: JBTM-2850 > URL: https://issues.jboss.org/browse/JBTM-2850 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > JTA 1.2 changed requirement: > "A transaction manager is, however, required to implicitly ensure the association of any associated XAResource is ended, via the appropriate XAResource.end call, immediately prior to completion;" > The change is that it no longer is confined to any associated ** resource **, but now specifies any associated ** XAResource ** > What is happening at the moment for two difference instance of an XAR but where isSameRM is true: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit > Post https://java.net/jira/browse/JTA_SPEC-3 this should be: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > DuplicateResource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2850) Call xa_end on duplicate XAResource as per JTA 1.2 specification

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2850: -------------------------------- Issue Type: Bug (was: Enhancement) > Call xa_end on duplicate XAResource as per JTA 1.2 specification > ---------------------------------------------------------------- > > Key: JBTM-2850 > URL: https://issues.jboss.org/browse/JBTM-2850 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.5.4.Final > > > JTA 1.2 changed requirement: > "A transaction manager is, however, required to implicitly ensure the association of any associated XAResource is ended, via the appropriate XAResource.end call, immediately prior to completion;" > The change is that it no longer is confined to any associated ** resource **, but now specifies any associated ** XAResource ** > What is happening at the moment for two difference instance of an XAR but where isSameRM is true: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit > Post https://java.net/jira/browse/JTA_SPEC-3 this should be: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > DuplicateResource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2850) Call xa_end on duplicate XAResource as per JTA 1.2 specification

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2850: -------------------------------- Issue Type: Task (was: Bug) > Call xa_end on duplicate XAResource as per JTA 1.2 specification > ---------------------------------------------------------------- > > Key: JBTM-2850 > URL: https://issues.jboss.org/browse/JBTM-2850 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.5.4.Final > > > JTA 1.2 changed requirement: > "A transaction manager is, however, required to implicitly ensure the association of any associated XAResource is ended, via the appropriate XAResource.end call, immediately prior to completion;" > The change is that it no longer is confined to any associated ** resource **, but now specifies any associated ** XAResource ** > What is happening at the moment for two difference instance of an XAR but where isSameRM is true: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit > Post https://java.net/jira/browse/JTA_SPEC-3 this should be: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > DuplicateResource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2850) Call xa_end on duplicate XAResource as per JTA 1.2 specification

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reopened JBTM-2850: --------------------------------- > Call xa_end on duplicate XAResource as per JTA 1.2 specification > ---------------------------------------------------------------- > > Key: JBTM-2850 > URL: https://issues.jboss.org/browse/JBTM-2850 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.5.4.Final > > > JTA 1.2 changed requirement: > "A transaction manager is, however, required to implicitly ensure the association of any associated XAResource is ended, via the appropriate XAResource.end call, immediately prior to completion;" > The change is that it no longer is confined to any associated ** resource **, but now specifies any associated ** XAResource ** > What is happening at the moment for two difference instance of an XAR but where isSameRM is true: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit > Post https://java.net/jira/browse/JTA_SPEC-3 this should be: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > DuplicateResource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2864) Add more tests for the JTS implementation of ExtendedJBossXATerminator

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2864?page=com.atlassian.jira.plugin.... ] Michael Musgrove closed JBTM-2864. ---------------------------------- Fix Version/s: (was: 5.later) Resolution: Rejected The untested interface method (which were added for the EJB subsystem) have tests have been deprecated in favour of using WFTC. PR https://github.com/jbosstm/jboss-transaction-spi/pull/23 added the deprecation whilst fixing https://issues.jboss.org/browse/WFLY-8275 > Add more tests for the JTS implementation of ExtendedJBossXATerminator > ---------------------------------------------------------------------- > > Key: JBTM-2864 > URL: https://issues.jboss.org/browse/JBTM-2864 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.5.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > ExtendedJBossXATerminator is our (extended) SPI interface for importing transactions and it has both JTA and JTS implementations. It is used by EJB in JTA mode which will be fully exercising the interface in JTA mode. However, we only test a subset of the interface in JTS mode (see com.arjuna.ats.jta.distributed.SimpleIsolatedServers) and these need extending to cover all of the methods. > Note that at least one of the methods is known not to produce the correct result, namely > {quote} > public Transaction getTransaction(Xid xid) throws XAException > {quote} > because the implementation uses XATxConverter to lookup the transaction but XATxConverter uses a different Xid format id from the one used by JTS so it will return null (instead of the transaction corresponding to the input xid). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2853) Transaction bridging for WS not working because of switch to new wfly transaction client

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2853?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2853. ------------------------------- > Transaction bridging for WS not working because of switch to new wfly transaction client > ---------------------------------------------------------------------------------------- > > Key: JBTM-2853 > URL: https://issues.jboss.org/browse/JBTM-2853 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: TxBridge > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 5.5.4.Final > > > Transaction bridging (WS transaction <-> global container transaction) does not work currently as container is impacted by switch from transaction spi (https://github.com/jbosstm/jboss-transaction-spi) to wildfly transaction client (https://github.com/wildfly/wildfly-transaction-client). > The cause code change could be checked here > https://github.com/wildfly/wildfly/commit/5eb816e0b58da3e99bfee81715ba27b... > Narayana needs to be enhanced to use the new transaction client to import transaction and bridge the ws to container transaction that way. The similar thing will probably need to be done for opposite side. > Container integration code in jboss container needs to be changed in way to provide the transaction context to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2851) Upgrade BlackTie to a version of WildFly that works with JDK9 (when available)

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2851?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2851: -------------------------------- Fix Version/s: 5.next (was: 5.5.4.Final) > Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) > ------------------------------------------------------------------------------ > > Key: JBTM-2851 > URL: https://issues.jboss.org/browse/JBTM-2851 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > > The blacktie-admin-service-ear is failed when deploying the ear to the wildfly running with the JDK9. It could be an issue [1] and should be fix in [2]. > So we have to build the openjdk-orb 8.0.8.Beta1-SNAPSHOT or wait it for the final release. > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-May/007698.html > [2] https://github.com/jboss/openjdk-orb/pull/4 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2850) Call xa_end on duplicate XAResource as per JTA 1.2 specification

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2850?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2850. ------------------------------- > Call xa_end on duplicate XAResource as per JTA 1.2 specification > ---------------------------------------------------------------- > > Key: JBTM-2850 > URL: https://issues.jboss.org/browse/JBTM-2850 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.5.4.Final > > > JTA 1.2 changed requirement: > "A transaction manager is, however, required to implicitly ensure the association of any associated XAResource is ended, via the appropriate XAResource.end call, immediately prior to completion;" > The change is that it no longer is confined to any associated ** resource **, but now specifies any associated ** XAResource ** > What is happening at the moment for two difference instance of an XAR but where isSameRM is true: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit > Post https://java.net/jira/browse/JTA_SPEC-3 this should be: > Resource1 start TMNOFLAGS > DuplicateResource1 start TMJOIN > Resource2 start TMNOFLAGS > Resource1 end TMSUCCESS > DuplicateResource1 end TMSUCCESS > Resource1 prepare > Resource2 end TMSUCCESS > Resource2 prepare > Resource1 commit > Resource2 commit -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-2833) Move deprecated tooling classes into an internal package

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2833?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2833: -------------------------------- Fix Version/s: 5.next (was: 5.5.4.Final) > Move deprecated tooling classes into an internal package > -------------------------------------------------------- > > Key: JBTM-2833 > URL: https://issues.jboss.org/browse/JBTM-2833 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Tooling > Affects Versions: 5.5.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > commit 66a9291f56f (JBTM-2308]) "Mark classes deprecated since we need to rejig package names" marked many/most of the tooling instrumentation classes deprecated - these need to be moved to internal packages and the then marked as not deprecated. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues March 2017