[JBoss JIRA] (JBTM-2671) TXBridge quickstart execution steps are inaccurate
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-2671?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-2671:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> TXBridge quickstart execution steps are inaccurate
> --------------------------------------------------
>
> Key: JBTM-2671
> URL: https://issues.jboss.org/browse/JBTM-2671
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Demonstrator, TxBridge, XTS
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Fix For: 5.next
>
>
> Execution steps for both wsat-jta-multi_hop and wsat-jta-multi_service quickstarts tells to start WildFly in one console and then execute the test with managed Arquillian container. Which is obviously wrong.
> We shouldn't suggest to start the container manually, but only use the managed container.
> Also, it might be good to not redirect output to the file, but instead print it directly and use egrep as showed in the current execution steps.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (JBTM-2334) Improve ease of use within Tomcat
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-2334?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-2334:
----------------------------------
Description:
Initial requirements:
# Implement a Narayana Tomcat module which provides an archive with all dependencies necessary for deployment on Tomcat: common, core, jta, jdbc, cdi, spi, jms (optional)
# Implement Tomcat lifecycle listener to bootstrap TM and RM
# Provide custom Narayana configuration file for Tomcat
# Provide context.xml with required configurations: lifecycle listener, UserTransaction, SynchronizationRegistry
# Add pooling to transactional driver (either implement it or use some library)
was:
It's still too difficult for people to do.
http://drieselliott.tumblr.com/post/99496743610/integrating-narayana-tran...
> Improve ease of use within Tomcat
> ---------------------------------
>
> Key: JBTM-2334
> URL: https://issues.jboss.org/browse/JBTM-2334
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: JTA
> Reporter: Mark Little
> Assignee: Gytis Trikleris
> Fix For: 5.next
>
>
> Initial requirements:
> # Implement a Narayana Tomcat module which provides an archive with all dependencies necessary for deployment on Tomcat: common, core, jta, jdbc, cdi, spi, jms (optional)
> # Implement Tomcat lifecycle listener to bootstrap TM and RM
> # Provide custom Narayana configuration file for Tomcat
> # Provide context.xml with required configurations: lifecycle listener, UserTransaction, SynchronizationRegistry
> # Add pooling to transactional driver (either implement it or use some library)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (JBTM-2740) Make the quickstart CI narayana.sh run script work on both clusters
by Michael Musgrove (JIRA)
Michael Musgrove created JBTM-2740:
--------------------------------------
Summary: Make the quickstart CI narayana.sh run script work on both clusters
Key: JBTM-2740
URL: https://issues.jboss.org/browse/JBTM-2740
Project: JBoss Transaction Manager
Issue Type: Task
Components: Build System
Affects Versions: 5.3.4.Final
Reporter: Michael Musgrove
Assignee: Michael Musgrove
Priority: Minor
Fix For: 5.next
The script does not run on the NCL cluster most likely due to hard coded paths.
Fixing this will be useful because the current config hard codes which set of quickstarts to run (which is not maintainable as we add and remove quickstarts).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2734:
-------------------------------------
Please can you provide a link in the reproducer to the repo where the test is?
> 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: Critical
> Fix For: 5.next
>
>
> 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