August 2016 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-2734: ---------------------------------- Component/s: JTA > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Priority: Minor > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-2734: ---------------------------------- Affects Version/s: 5.3.3.Final > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Priority: Minor > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka reassigned JBTM-2734: ------------------------------------- Assignee: Tom Jenkinson > EIS can't recover transaction when heuristic outcome happens > ------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Minor > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2733) Adding section about inflow transactions and EIS interaction

by Ondra Chaloupka (JIRA)

Ondra Chaloupka created JBTM-2733: ------------------------------------- Summary: Adding section about inflow transactions and EIS interaction Key: JBTM-2733 URL: https://issues.jboss.org/browse/JBTM-2733 Project: JBoss Transaction Manager Issue Type: Enhancement Components: Documentation Affects Versions: 5.3.4.Final Reporter: Ondra Chaloupka I would like ask for enhancing Narayana documentation for section where information about inflow transactions and interaction with EIS would be part of. This ask for the addition came from discussion about behaviour of inflow transaction on jbossts mailing list. Particularly information how EIS and TM is expected to interoperate during recovery process. E.g. how EIS is expected to finish transaction when TM jvm crash occurs or how EIS is expected to finish transaction when participant of txn involved under management of TM (TM is manager of subordinate transaction) and such participant independently decides to rollback (after prepare is confirmed) which causes heuristic exception being thrown to EIS RAR and transaction is put to heuristic state. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2704) Compensations framework cannot instantiate bean from ear archive

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2704?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Tom Jenkinson created pull request #9121 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Reopened) > Compensations framework cannot instantiate bean from ear archive > ---------------------------------------------------------------- > > Key: JBTM-2704 > URL: https://issues.jboss.org/browse/JBTM-2704 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed. > Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager. > It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2732) pre-release.sh does not allow tagging to proceed when error does not exist

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2732?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2732. ------------------------------- > pre-release.sh does not allow tagging to proceed when error does not exist > -------------------------------------------------------------------------- > > Key: JBTM-2732 > URL: https://issues.jboss.org/browse/JBTM-2732 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.3.4.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2732) pre-release.sh does not allow tagging to proceed when error does not exist

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2732?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-2732. --------------------------------- Resolution: Done > pre-release.sh does not allow tagging to proceed when error does not exist > -------------------------------------------------------------------------- > > Key: JBTM-2732 > URL: https://issues.jboss.org/browse/JBTM-2732 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.3.4.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2732) pre-release.sh does not allow tagging to proceed when error does not exist

by Tom Jenkinson (JIRA)

Tom Jenkinson created JBTM-2732: ----------------------------------- Summary: pre-release.sh does not allow tagging to proceed when error does not exist Key: JBTM-2732 URL: https://issues.jboss.org/browse/JBTM-2732 Project: JBoss Transaction Manager Issue Type: Task Reporter: Tom Jenkinson Assignee: Tom Jenkinson Priority: Blocker Fix For: 5.3.4.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2731) Fix update_jira.py script

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2731?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2731: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Fix update_jira.py script > ------------------------- > > Key: JBTM-2731 > URL: https://issues.jboss.org/browse/JBTM-2731 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.3.4.Final > > > WFLY project used to have an issue type with the typo ("Component Upgrade" with double space). It seems to have been fixed, so typo should be removed from the script too. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2731) Fix update_jira.py script

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2731?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2731. ------------------------------- > Fix update_jira.py script > ------------------------- > > Key: JBTM-2731 > URL: https://issues.jboss.org/browse/JBTM-2731 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.3.4.Final > > > WFLY project used to have an issue type with the typo ("Component Upgrade" with double space). It seems to have been fixed, so typo should be removed from the script too. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues August 2016