I understand the point about the distributed environment but my perspective is to be setup similarly as in WildFly. With other runtimes the Narayana supports (Tomcat, Quarkus) the basic configuration would be good to be consistent (and agree, consistent for JTA).

The current `jboss-properties.xml` defines the SubordinationManagerXAResourceOrphanFilter which is for handling subordinate transactions.

As looking into the configurations I think besides adding that orphan filter the default configuration should enable the `CommitMarkableResourceRecordRecoveryModule` as well.

Yes, that sounds rational to me.

Then the `SubordinationManagerXAResourceOrphanFilter` would be good to remove from `narayana-jta`. The `CommitMarkableResourceRecordRecoveryModule` should be added on the other side.

It could be a bit picky but maybe other jbosst-properties.xml should be considered this way. E.g. ArjunaJTS/narayana-jts-idlj/src/main/resources/jbossts-properties.xml defines the same set of the orphan filters and could be the `SubordinationManagerXAResourceOrphanFilter` should be retained there. But then probably the SubordinateJTAXAResourceOrphanFilter makes sense as well.

I assume that the SubordinationManagerXAResourceOrphanFilter should not be removed from the JTS properties.xml files. It works with the SubordinateAtomicActionRecoveryModule which is in use for JTA and JTS. As the javadoc of the orphan filter says:

it can check with the SubordinationManager if the transaction is in flight during orphan detection

As the JTS allows the remote processing and subordinate transactions I think it's logic to have it defined. And in fact as looking into the code the SubordinationManagerXAResourceOrphanFilter is the only orphan filter which works with JTS.

I created a jira [JBTM-3216] Narrow the default recovery configuration in the jbossts-properties.xml files  and PR for it [JBTM-3216] narrow and fix recovery setup in jbossts-properties.xml descriptors by ochaloup · Pull Request #1524

tomjenkinson agree. I think CMR could be permitted for JTS for the cases you mentions. I can see the documentation does not declare any limitation - Chapter 11. Java Transaction API (JTA) Red Hat JBoss Enterprise Application Platform 7.2 | Red Hat Customer Portal but what I remember the CMR is tested with JTA mode only.

Then it's question if it should be narrowed for forbidding to use CMR for JTS - we would need to ensure that Narayana started with JTS does not permit usage of CMR - by removing the recovery module from configuration. Or if the current way is fine and we could maybe just enhance the documentation.

I'm here inclined to opinion that CMR on local JTS is fine and possible.

Yes, I noted that the filter list is not conditional to JTS which does not do any trouble as the orphan filters checks about the record type and it works with it only when it's the JTA record. So when JTS is under usage then orphan detection filters do nothing as they are meant only for JTA records.

But we could narrow it down and set-up the orhan filters only when JTA is enabled. Do you think?

What I found interesting now is a situation when a user starts transactions with JTA. Then he kills the app server in middle of processing. He decides to switch to JTS. He starts the app server once again. There could be several JTA transaction records in the object store. These transaction records could never be removed (or potentially in a wrong way).

I consider this as a minor or only developer side effect. I can't imagine that somebody changes JTA mode to JTS on production servers.

Ondra

tomjenkinson I verified in the code and I misinterpreted my understanding. Now I consider the "wrong way" that there could be left some transactions untouched.

In fact, having enabled the orphan filters even for JTS makes switching between JTA to JTS kind of "safer". When there is left some JTA transaction which have no record in Narayana object store but which were prepared in e.g. database then such prepared participant record will be rolled-back by orphan detection even when JTS mode is enabled.

Hi tomjenkinson. I see what you mean. I was assuming that it could be potential issue so it took me some time to get to the testing part. But from what I can see there is no issue here.

The SubordinateAtomicActionRecoveryModule will load only records which were created during the JTA mode. It should not be processing the JTS ones as there is no subordinate

recoveryStore.allObjUids(SubordinateAtomicAction.getType(), states)

I assume it can't happen that the JTS transaction is loaded by the recovery module. The SubordinationManagerXAResourceOrphanFilter uses the SubordinateAtomicActionRecoveryModule to verify an existence of an execution error. That orphan filter needs the module to be loaded for working correctly.

From the code point of view it seems that it should be safe as the recovery module won't load the JTS ones as JTS has the SubordinateAtomicTransaction type. And the recovery module does not operate with the common com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporter interface.

On the testing perspective: I tried to create a JTA object store record and left an "JTA" participant record for presumed rollback and when I switched for recovery for JTS mode all was processed ok.

I haven't run some exhaustive test coverage (as I need to do it manually per testcase) but if I didn't miss something it should be fine from the recovery perspective.

Ondra