Suggestion for a new compensations subsystem

[gytis]

Currently compensations bootstrap happens in the transactions subsystem. It registers deployment processor to scan the annotations and add the dependencies if necessary. This is not expensive and doesn't cause any issues other than adding the dependencies to the transactions subsystem. However, I'm currently finishing off the recovery implementation and more bootstrap logic will be needed. In addition, two more recovery modules will have to be registered: one for the participant (a new one) and one for the coordinator (from XTS). This will require to add XTS dependency too.

The whole compensations bootstrapping will not need a lot of code. However, I'm thinking maybe it would be good to pull it out to the separate subsystem in order to maintain the separation of concerns.

Does anybody know any reason why this could be a bad idea?

Thanks,

Gytis

[marklittle]

Could you give more specific details?

[gytis]

This is a compensations deployment processor currently living in the transactions subsystem: wildfly/CompensationsDependenciesDeploymentProcessor.java at master · wildfly/wildfly · GitHub. It doesn't do much, just scans for annotations and adds module dependency to the deployment.

For local compensations recovery I need to enable BACoordinatorRecoveryModule (narayana/BACoordinatorRecoveryModule.java at master · jbosstm/narayana · GitHub ) which currently is enabled by XTS subsystem.

In addition to BACoordinatorRecoveryModule I have implemented LocalParticipantRecoveryModule (narayana/LocalParticipantRecoveryModule.java at master-JBTM-1107-compensations-recovery · gytis/narayana · GitHub ) which also needs to be enabled. It is needed for a scenario when crash happens after participant is completed but before the coordinator was asked to complete the transaction.

All of the above are needed for local compensations. Therefore, they don't belong to XTS and would go to the transactions subsystem.

[marklittle]

So you're thinking of pulling them into ArjunaCore, or something else? That's the piece I'm missing.

[gytis]

Ah I must have been clearer. By subsystem I mean WildFly subsystem.

[tomjenkinson]

I don't think we can make transactions WildFly subsytem depend on XTS WildFly subsystem as that would be cyclic: wildfly/pom.xml at master · wildfly/wildfly · GitHub

A compensations subsystem might be useful because the transactions WildFly subsystem has historically been to provide JTA/JTS capabilities to WildFly so if you now wanted to build a container on WildFly that just had compenstations, NoSQL etc (rather than JTA) it might be nice.

[gytis]

It wouldn't cause cyclic dependency because I'm adding a Maven dependency on XTS rather than a dependency on WildFly XTS subsystem. That's how I'm testing things now and it works. However, it makes transactions subsystem (which as you say is for JTA and JTS) more messy and complicated.

I agree on the benefits you've  mentioned.

[tomjenkinson]

I think we should proceed with this then.