[JBoss JIRA] (JBTM-3065) Check that starting LRA's via CDI and API in the same method works
by Tom Jenkinson (Jira)
[ https://issues.jboss.org/browse/JBTM-3065?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-3065:
--------------------------------
Fix Version/s: 5.next
(was: 5.9.3.Final)
> Check that starting LRA's via CDI and API in the same method works
> ------------------------------------------------------------------
>
> Key: JBTM-3065
> URL: https://issues.jboss.org/browse/JBTM-3065
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Affects Versions: 5.9.0.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Major
> Fix For: 5.next
>
>
> The LRA spec supports starting LRA's via a Java API or via Java annotations. If the two approaches are used together in the same resource method then the LRA started via the API should be nested inside the one started by an annotation.
> If the annotated class also contains @Compensate and @Complete annotations (which means that the resource should join the outer LRA) and the resource method Joins the nested LRA then the resource should receive callbacks for both the outer and nested LRA's.
> The following code shows an example:
> {code}
> @PUT
> @LRA(LRA.Type.REQUIRES_NEW) // starts a new LRA on entry
> public String doInTransaction() {
> URL lraId = lraClient.startLRA(...); // starts a nested LRA
> lraClient.join(...) // join the nested LRA
> lraClient.closeLRA(lraId); // close the nested LRA
> // assert that the nested callbacks were invoked
> // assert that the callbacks for the outer LRA have not been called yet
> }
> {code}
> Similar comments apply if the resource joins via the LRAManagement API:
> {code}
> @Inject
> private LRAManagement lraManagement;
> public String doInTransaction() {
> lraManagement.joinLRA(this, lraId, 0L, TimeUnit.SECONDS);
> // etc
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (JBTM-3072) Add a test to verify the behaviour of LRA.Type.REQUIRES_NEW combined with LRA.delayClose
by Tom Jenkinson (Jira)
[ https://issues.jboss.org/browse/JBTM-3072?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-3072:
--------------------------------
Fix Version/s: 5.next
(was: 5.9.3.Final)
> Add a test to verify the behaviour of LRA.Type.REQUIRES_NEW combined with LRA.delayClose
> ----------------------------------------------------------------------------------------
>
> Key: JBTM-3072
> URL: https://issues.jboss.org/browse/JBTM-3072
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: LRA, Testing
> Affects Versions: 5.9.0.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Priority: Major
> Fix For: 5.next
>
>
> Add a test that verifies the correct behaviour when a method is annotated with both REQUIRES_NEW and delayClose, ie something like:
> {code}
> @PUT
> @Path(ActivityController.ACCEPT_WORK)
> @LRA(value = LRA.Type.REQUIRES_NEW, delayClose = true)
> public Response doInNewLRA( ....) {...}
> {code}
> The expected behaviour is:
> {code}
> /**
> * If called outside a LRA context a new LRA will be created for the
> * the duration of the method call and when the call completes it will
> * be closed (this behaviour can be overridden using the
> * {@link LRA#delayClose} attribute).
> *
> * If called inside a LRA context it will be suspended and a new LRA
> * context will be created for the duration of the call. When the method
> * finishes this new LRA will be closed and the original context will be
> * resumed. This behaviour can be overridden using the
> * {@link LRA#delayClose} attribute) in which case the original LRA
> * remains suspended and the new LRA becomes the active one and only
> * when that one is terminated will the original context be resumed.
> */
> REQUIRES_NEW,
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months