Refactoring TXFramework (AKA Compensations API) Proposal

[paul.robinson]

There are a number of refactorings that I think should be made to TXFramework (AKA Compensations API). In this post I'll present my ideas for the community to review.

1) Remove the old TXFramework API (JBTM-2221).

The original TXFramework API focused on bringing usability improvements to ACID and Compensating transactions. The ACID improvements related to WS-AT and REST-AT and were thus moved over to those components. Also, those improvements specific to WS-BA were also moved over to XTS. Last summer an API was developed that focused just on Compensating Transactions. There is now no need to keep around the remnants of the TXFramework API, so it should be removed.

2) Package name change 'org.jboss.narayana.compensations' -> 'org.jboss.narayana.compensations.cdi' (JBTM-2223)

The current package name doesn't leave any room for other APIs. For example, the Hibernate OGM team have expressed an interest in using Compensating Transactions. I also think something could be done with Vert.X, Fuse and maybe LiveOak. Changing the package name would be best done sooner rather than later.

3) Rename TXFramework -> Compensations (JBTM-2222)

As stated in 1), TXFramework now just focuses on Compensating transactions. The ACID transaction improvements have been moved into XTS and REST components. Therefore, I think we should drop the TXFramework name in favour of "Compensations" or "Compensating Transactions".

4) Move Compensations dependency adder to transactions subsytem (JBTM-2224)

The XTS WildFly SubSystem has some code that detects the usage of the Compensating transactions API and then adds the required dependencies to the application. The XTS SubSystem is only loaded in the standalone-xts.xml configuration. This has become a problem, since the Compensating transactions API can now also be used with the standalone.xml configuration for local-only transactions. Therefore, I think we should move this dependency adding code into the Transactions SubSystem so that the required dependencies are added regardless of which WildFly configuration is used.

I have raised a Pull Request for these changes: https://github.com/jbosstm/narayana/pull/688.

Thanks,

Paul.

[marklittle]

What deprecation rules were you thinking about using? Most of these changes represent significant modifications to the public APIs and typically these should only occur in a major revision of the project.

[paul.robinson]

Mark,

I agree. This was one of the reasons why I've delayed making these changes. The target version of WildFly is 9.0.0.Alpha1, so I thought now would be a good time to do this.

Paul.

[marklittle]

OK, but which major version of Narayana? Plus you should deprecate where possible rather than just going for a full removal immediately. Maybe you can deprecate in minor versions of Narayana between here and the major version (6?) which at least gives people an idea that these changes are coming?

[paul.robinson]

Mark,

The next version of Narayana is 5.0.3.Final. However, I hadn't been too concerned with the Narayana version, as this feature (currently) only works inside WildFly. Hence I was thinking more about making the change during the right WildFly version.

For "1) Remove the old TXFramework API (JBTM-2221)" I agree that deprecating it in WildFly 9.0.0.Alpha1 with a view to removing it by a late 9.0.0.Beta would be a more developer-friendly approach to take.

For "2) Package name change 'org.jboss.narayana.compensations' -> 'org.jboss.narayana.compensations.cdi' (JBTM-2223)", I'm not sure there is  simple way of providing a deprecation phase. In which case, I think it's probably better doing it as early in WildFly's release schedule as possible (i.e. now).

For "3) Rename TXFramework -> Compensations (JBTM-2222)", I think it makes more sense to do once the TXFramework API has gone (i.e item 1 is complete).

For "Move Compensations dependency adder to transactions subsytem (JBTM-2224)", I think it can be done now as there is no negative impact on the developer.

Paul.

[marklittle]

I think you are wrong in ignoring the Narayana community and stand-alone use cases. You are suggesting making a significant API change within the scope of a micro release?! I do not think that is right and definitely wouldn't be happy to see this happen.

[jesper.pedersen]

This change has broken ALL existing pom.xml, ivy.xml and Gradle build.gradle files that are using Narayana 5.0.x series - and possibly more. I'm not going to check what else broke...

IMHO, this needs to be reverted, and a 5.0.5.Final release made. Then schedule the change for Narayana 5.1 or 6.0.

[tomjenkinson]

I am not really sure how you can say it has broken ALL existing pom.xml files. For people that were including the deprecated TXF code they would still need to modify their poms anyway (version 5.0.4 -> 5.0.5).

No Java APIs were broken - that was the point of the change. That being said, if people want to code against the deprecated TXF API still it would be simpler for them if only the V in GAV changed - I do agree there. As such I have raised https://github.com/jbosstm/narayana/pull/819/files which leaves the deprecated code in the old location.

Thanks for the report,

Tom

[mmusgrov]

Paul Robinson wrote:

4) Move Compensations dependency adder to transactions subsytem (JBTM-2224)

The XTS WildFly SubSystem has some code that detects the usage of the Compensating transactions API and then adds the required dependencies to the application. The XTS SubSystem is only loaded in the standalone-xts.xml configuration. This has become a problem, since the Compensating transactions API can now also be used with the standalone.xml configuration for local-only transactions. Therefore, I think we should move this dependency adding code into the Transactions SubSystem so that the required dependencies are added regardless of which WildFly configuration is used.

Making the transaction subsystem dependent on the compensation API is pulling in a lot of extra dependencies that the vast majority of users do not need. Can we move it back out again and find another solution for systems that specifically want to use these annotations.

[marklittle]

Makes sense but would it be possible to give some specifics on what else is being pulled in?

[mmusgrov]

The main problem is that the compensations framework depends on XTS (org.jboss.narayana.xts:jbossxts) which in turn pulls in a number of other dependencies that not required by transactions proper. We should either extract compensation specifics into its own artifact or remove it from the wildfly transaction subsystem. We need input from Paul and Gytis to see which is the best way to proceed.

[paul.robinson]

I'll need to investigate fully. But my initial thoughts are:

When using WildFly without XTS, you can only use local compensations. This is just a thin-ish wrapper of the SagaModel so not much is needed from XTS. I suspect we can just make a smaller dependency that just includes this and leaves the rest of XTS out.

Paul.

[marklittle]

OK that's definitely not good. ArjunaCore shouldn't know about transports. Why is the compensation framework not fairly abstract in ArjunaCore with specific bindings provided in the other modules? That's pretty much the approach we took back in HP for BTP with compensations supported within 'Core but bindings to SOAP where done in WST.

[paul.robinson]

Mark,

I think you might have misunderstood me. The ArjunaCore classes don't know about transports. In fact I never wrote/changed any for this work. I just made use of the classes such as 'com.arjuna.mw.wscf11.model.sagas.CoordinatorManagerFactory'  which lives in '/XTS/WSCF/classes/com/arjuna/mw/wscf11/model/sagas/CoordinatorManagerFactory.java.'

Paul.

[marklittle]

OK so what's Mike complaining about ?