[jbossts-issues] [JBoss JIRA] (JBTM-3239) Failing AfterLRA participant calls are not repeated

Ondrej Chaloupka (Jira) issues at jboss.org
Mon Jan 6 04:01:04 EST 2020


    [ https://issues.redhat.com/browse/JBTM-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13941422#comment-13941422 ] 

Ondrej Chaloupka edited comment on JBTM-3239 at 1/6/20 3:59 AM:
----------------------------------------------------------------

The participant is {{Completed/Compensated}} when the HTTP REST call, to the appropriate participant's method, finishes with success. The {{AfterLRA}} is only an additional announcement that informs how the whole(!) LRA finished. In other words the {{AfterLRA}} does not influence the final state of the participant.

What is meant by the "forget" in your question? It could be I missed something.
To summarize my perspective - the participant may define a method annotated with {{@Forget}} which could be invoked by coordinator to inform the participant that there is no more need to retain information about the particular LRA. This forget call is connected to the transaction management of the participant. The {{AfterLRA}} is an additional information on top of it.
For the LRA transaction would be safe as whole then even the participant has to provide some "guarantee" defined in the LRA protocol. This guarantee means that the participant needs to retain and persist some information until it's said by coordinator that the participant has free to remove it.
>From the spec (and my understanding) the {{@Forget}} is usable only when nested transaction (nested LRA) is in use. Then the coordinator may call e.g. {{@Complete}} on participant but there is still some chance thatn {{@Compensate}} will be called on the same LRA id. The participant has to persist this until the {{@Forget}} is invoked.
Now the {{AfterLRA}} does not requires such "guarantee". It's up to the participant if it knows what to do with the {{AfterLRA}} call or if such information is just left unused. In other words the {{Forget}} and {{AfterLRA}} have not connection. The participant is not forced to retain/persist any information for {{AfterLRA}} working properly and safely.


was (Author: ochaloup):
The participant is {{Completed/Compensated}} when the HTTP REST call, to the appropriate participant's method, finishes with success. The {{AfterLRA}} is only an additional announcement that informs how the whole(!) LRA finished. In other words the {{AfterLRA}} does not influence the final state of the participant.

What is meant by the "forget"? It could be I missed something but the participant may define a method annotated with {{@Forget}} which could be invoked by coordinator to inform the participant that there is no more need to retain information about the particular LRA. This forget call is connected to the transaction management of the participant. The {{AfterLRA}} is an additional information on top of it.
For the LRA transaction would be safe as whole then even the participant has to provide some "guarantee" defined in the LRA protocol. This guarantee means that the participant needs to retain and persist some information until it's said by coordinator that the participant has free to remove it.
>From the spec (and my understanding) the {{@Forget}} is usable only when nested transaction (nested LRA) is in use. Then the coordinator may call e.g. {{@Complete}} on participant but there is still some chance thatn {{@Compensate}} will be called on the same LRA id. The participant has to persist this until the {{@Forget}} is invoked.
Now the {{AfterLRA}} does not requires such "guarantee". It's up to the participant if it knows what to do with the {{AfterLRA}} call or if such information is just left unused. In other words the {{Forget}} and {{AfterLRA}} have not connection. The participant is not forced to retain/persist any information for {{AfterLRA}} working properly and safely.

> Failing AfterLRA participant calls are not repeated
> ---------------------------------------------------
>
>                 Key: JBTM-3239
>                 URL: https://issues.redhat.com/browse/JBTM-3239
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>          Components: LRA
>    Affects Versions: 5.10.1.Final
>            Reporter: Martin Stefanko
>            Assignee: Martin Stefanko
>            Priority: Major
>




--
This message was sent by Atlassian Jira
(v7.13.8#713008)


More information about the jbossts-issues mailing list