[JBoss JIRA] (JBTM-1952) Implement XTSATRecoveryManager and XTSBARecoveryManager injection
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1952?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1952:
----------------------------------
Description:
Change polling introduced with JBTM-1917 with proper CDI injection.
See JBTM-1639 for the detailed background on the issue before JBTM-1917 workaround.
was:Change polling introduced with JBTM-1917 with proper CDI injection.
> Implement XTSATRecoveryManager and XTSBARecoveryManager injection
> -----------------------------------------------------------------
>
> Key: JBTM-1952
> URL: https://issues.jboss.org/browse/JBTM-1952
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: XTS
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Fix For: 6.later
>
>
> Change polling introduced with JBTM-1917 with proper CDI injection.
> See JBTM-1639 for the detailed background on the issue before JBTM-1917 workaround.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (JBTM-1639) Improve XTS Api for looking up Recovery Manager to prevent developer from poling
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1639?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris resolved JBTM-1639.
-----------------------------------
Fix Version/s: (was: 5.next)
Resolution: Out of Date
This was resolved by https://issues.jboss.org/browse/JBTM-1917
> Improve XTS Api for looking up Recovery Manager to prevent developer from poling
> --------------------------------------------------------------------------------
>
> Key: JBTM-1639
> URL: https://issues.jboss.org/browse/JBTM-1639
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: XTS
> Reporter: Paul Robinson
> Assignee: Gytis Trikleris
>
> Currently the developer needs to poll for the RecoveryManager as it's possible that the application can be deployed before the XTS subsystem has finished startup.
> This issue was worked around in JBTM-1522 and in the TXBridge tests, by having the application poll until the RM was not null.
> Two possible solutions:
> Have a blocking call to XTSATRecoveryManager.getRecoveryManager() that doesn't return until there is an RM available. if we use the existing java method, we need to analyse all usages to make sure returning null is not a valid outcome.
> Another solution is to find out how to delay the application's initialisation until after XTS has started. This puts the burden on the application developer to implement, but requires no changes to the XTS code. See JBTM-1522 for alternative mechanisms for initialising the application. I tried three and none of them fired after the server had booted.
> To Reproduce
> Put breakpoints on:
> Application's usage of: XTSATRecoveryManager.getRecoveryManager(); //Stop all threads
> XTSATRecoveryManager.setRecoveryManager() // stop on Thread only
> Copy your application to the deploy directory (xtstest.war is a good choice). Now start the server with debugging enabled (suspend=y). To reproduce this you will see the XTSATRecoveryManager.setRecoveryManager() BP fire, and then shortly after the XTSATRecoveryManager.getRecoveryManager() BP will fire. Allow the getRecoveryManager to continue and you will notice it is null. Fix this problem, and the getRecoveryManager will wait until the setRecoveryManager is complete and thus always return a non-null RM.
> Once this is fixed, find all occurrence of the polling work-around and have them use the solution to this issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (JBTM-2458) Think of the possibility to improve Compensations API with lambdas
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-2458?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris commented on JBTM-2458:
---------------------------------------
One of the Tom's suggestions during the Narayana f2f:
{code}
BusinessLogic foo = () -> collectionWrapper.updateOne();
tx.begin();
foo(); // annotations on it
tx.commit();
tx.begin();
tx.onFailure(compensationHandler).onSuccess(confirmationHandler).enlist(foo);
tx.onFailure(compensationHandler2).enlist(foo2);
tx.commit()
{code}
> Think of the possibility to improve Compensations API with lambdas
> ------------------------------------------------------------------
>
> Key: JBTM-2458
> URL: https://issues.jboss.org/browse/JBTM-2458
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: TXFramework
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Priority: Minor
> Fix For: 5.next
>
>
> Emmanuel suggested to reduce verbosity in Compensations API by making it possible to use lambdas for handler implementation.
> We should try to think of the best API changes to introduce that.
> We could rewrite MongoDB quickstart to make it easier to visualise the difference.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months