Compensations API updates

[gytis]

Some time ago Emmanuel suggested that we could allow using Lambdas for handler implementations in Compensations API. In addition to the currently used approach to provide different class for every different handler and adding it to the annotation so that instance would be created only during confirm/close/compensate steps. This approach could make the API a little less verbose. However, it requires API change and annotations could not be used to register an instance of the handler (annotation only takes a class name).

During the Narayana f2f meeting tomjenkinson suggested one example and I added a couple. I wrote quick implementations for two of them and they are bellow with the pseudo code. Please give your thoughts on the idea and the examples if in your opinion this would be useful. Other API suggestions would also be appreciated.

First example ([JBTM-2458] Tom's example from the comment · gytis/narayana@92378de · GitHub:

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()

Second example ([JBTM-2458] Think of the possibility to improve Compensations API wit… · gytis/narayana@2ce55f2 · GitHub:

public interface Action {
    void execute();
}

public interface CompensatableAction {
    List<CompensationHandler> getCompensationHandlers();
    List<ConfirmationHandler> getConfirmationHandlers();
    List<TransactionLoggedHandler> getTransactionLoggedHandlers();
    Action getAction();
}

public final class CompensatableActionBuilder() {
    CompensatableActionBuilder addCompensationHandler(CompensationHandler compensationHandler);
    CompensatableActionBuilder addConfirmationHandler(ConfirmationHandler confirmationHandler);
    CompensatableActionBuilder addTransactionLoggedHandler(TransactionLoggedHandler transactionLoggedHandler);
    CompensatableActionBuilder addAction(Action action);
    CompensatableAction build();
}

tx.begin();
tx.enlist(compensatableAction);
tx.commit();

[tomjenkinson]

In terms of the first example, is it possible to achieve something like:

tx.enlist(foo2).onFailure(compensationHandler).onSuccess(confirmationHandler);

[gytis]

Particularly first example is implemented in a way, that enlist method does the enlistment of the handlers and triggers action execution. Therefore, calling it before onFailure and onSuccess would mean that it will not register any handlers. See [JBTM-2458] Tom's example from the comment · gytis/narayana@92378de · GitHub. Is there a particular reason to push it before onFailure and onSuccess?

[tomjenkinson]

Actually I think it was my misunderstanding. Do those handlers just apply to subsequent actions that is enlisted.

In other words, is this correct:

        transaction.begin();

        transaction.enlist(action1); // _NO_ handlers called on action1 - maybe this is an error condition?

        transaction.onSuccess(conf1);

        transaction.onFailure(comp1);

        transaction.enlist(action2); // conf1 or comp1 called on action 2

        transaction.onSuccess(conf2);

        transaction.enlist(action3); // conf2 or comp1 called on action 3

        transaction.onFailure(comp2);

        transaction.enlist(action4); // conf2 or comp2 called on action 4

        transaction.commit||rollback

[gytis]

Exactly. However, keep in mind that these are just quick mockups, so implementations are not smart.

[tomjenkinson]

I actually like either version but what I am not sure of is (at least in the gist) where the lambda is? Also the lambda for the first example only seems to appear in your post and not on your gist. I might be missing something though.

[gytis]

Lambda is an implementation of the functional interface, so you can use them to implement compensation/confirmation handlers. However, to register them we need to allow registering objects rather than classes. So that's the main change in the API.

I didn't add them to the examples, because examples are in the Narayana code base, which is set for the older version of Java. However, when writing a client application you can do handler implementations with lambdas.

[tomjenkinson]

With the second example I guess you would always need to specify the handlers. That may nor may not be desirable.

[gytis]

You can always leave the handler lists empty. Also I'm sure that we should leave the current API too.

[tomjenkinson]

I was meaning, if you have two actions that share the same handler you have to wire in the handler twice into the CompensatableAction instance - unlike the first example where you can see the handler and subsequent actions know to use the same one.

I guess the frequency of that is not enough to make a difference but if anyone has feedback on that it would be useful.

[gytis]

The problem is that handlers are business logic and we cannot guess how they are being used. But my opinion is that having one handler for two actions would be a bad design. Also, if really necessary handlers could share state somehow so that second handler could check if the first has executed.

By the way, first example, as is implemented at the moment, registers handlers only for the next enlisted action and then clears them.

The same thing applies for the current implementation. No mater how many times you call the same @Compensatable method, it will register new handlers every time.

[tomjenkinson]

I agree - lets go with the second approach.

[tomjenkinson]

After a face-to-face meeting we came up with: [JBTM-2622] Implement possible new compensations api from the meeting - JBoss Issue Tracker Gytis is going to try to protoype that are report back.

[gytis]

I've put together a working example of the API from our meeting in Newcastle. I've raised a pull request in order to make it easier to comment on the code, however I do not intend to merge it [1]. I does have three commits, but the one with the API is "[JBTM-2622] Possible new compensations api from the meeting". Feel free to poke at it and provide me your thoughts.

[1] [JBTM-2622] Implement possible new compensations api from the meeting by gytis · Pull Request #4 · gytis/narayana · GitH…

[tomjenkinson]

Its worth tagging paul.robinson too here to see if he would like to take a look.