Default orphan filtes for the Narayana distribution

[ochaloup]

Hi,

I would like to check with you one thing.

I found that the default recovery orphan filters are defined here

narayana/jbossts-properties.xml at master · jbosstm/narayana · GitHub

Those are

com.arjuna.ats.internal.jta.recovery.arjunacore.JTATransactionLogXAResourceOrphanFilter
com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter
com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinationManagerXAResourceOrphanFilter

I think it would be reasonable to add

com/arjuna/ats/internal/jta/recovery/arjunacore/SubordinateJTAXAResourceOrphanFilter

as the default filter. What do you think?

Ondra

[tomjenkinson]

I would note that WildFly does include this one: wildfly/JTAEnvironmentBeanService.java at 1bf993be72b570a0c780a58ba05cabafe1ce7935 · wildfly/wildfly · GitHub

What I could say is that this only really makes sense in a distributed (and non-JTS) environment (e.g. JCA or things that might layer on our implementation classes for that), so would be narayana-jta specific (indeed, as your link points to - there are other jbossts-properties for JTS).

As such I think it might not be necessary but I would also be open to reasons we might consider adding it.

[ochaloup]

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.

[tomjenkinson]

I don't think the Quarkus/Tomcat environments support distributed (remote) transaction propagation do they?

It's a good point about SubordinationManagerXAResourceOrphanFilter. A related question would be therefore whether it should perhaps be removed from the narayana-jta ones? It looks like I added it in JBTM-2685 Provide a mechanism to detect if there is a locally running… · jbosstm/narayana@4ea294c · GitHub  for [JBTM-2955] Add a filter that checks for running subordinate transactions before identifying a branch as orphaned - JBos…  (not the issue in the commit message, that looks to be unrelated). It might be clearer to remove this filter from the standalone set up.

[ochaloup]

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.

[tomjenkinson]

I would agree. I would tend to removing SubordinationManagerXAResourceOrphanFilter from narayana-jta. I think adding CommitMarkableResourceRecordRecoveryModule is also reasonable.

SubordinateJTAXAResourceOrphanFilter would not be useful in the JTS ones as it relates to non-CORBA based subordination.  I think we can remove the SubordinationManagerXAResourceOrphanFilter from https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/narayana-jts-idlj/src/main/resources/jbossts-properties.xml#L70 (etc) too for the same reason, it shouldn't happen in the JTS environment. CommitMarkableResourceRecordRecoveryModule shouldn't be added to JTS as it is not expected to work in a distributed transaction environment.

[ochaloup]

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]

Hi ochaloup I am thinking that we probably want to reflect these in the WildFly configs we are using too.

I spotted CMR even in the JTS case which it must not be allowed in any distributed case: wildfly/ArjunaRecoveryManagerService.java at 3ba60f7b571e65eacb67d27a5c07e31843520baf · wildfly/wildfly · GitHub (perhaps it is there to support use cases where all the transaction is in one JVM and only the single CMR is added?)

I noted the filter list is not conditional if JTS is enabled: wildfly/JTAEnvironmentBeanService.java at master · wildfly/wildfly · GitHub

[ochaloup]

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]

ochaloup  wrote:

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.

I think if this could occur in the "wrong way" (and here I interpret that as data integrity issue then we have a blocker issue. However, if they are just left alone then yeah, I see that just a side effect that could be explained.

Do you think there is a data integrity issue if the mode is switched and the same object store is used?

/cc mmusgrov

[ochaloup]

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.

[tomjenkinson]

Thanks for checking ochaloup - what did you think about narayana/SubordinateAtomicActionRecoveryModule.java at master · jbosstm/narayana · GitHub  what would happen in the case that the JTA imported transaction was tried to be loaded as a JTS imported transaction? Is that expected? I found it when looking at narayana/SubordinationManagerXAResourceOrphanFilter.java at master · jbosstm/narayana · GitHub

[ochaloup]

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

[mmusgrov]

How does the correct answer relate to the original question which was "whether or not to add com/arjuna/ats/internal/jta/recovery/arjunacore/SubordinateJTAXAResourceOrphanFilter to the set of default orphan filters?

[tomjenkinson]

Hi Mike,

The answer summarises the decision of the discussion primarily by it's reference to https://issues.jboss.org/browse/JBTM-3216  and [JBTM-3216] narrow and fix recovery setup in jbossts-properties.xml descriptors by ochaloup · Pull Request #1524 · jboss…  where you can see we did not add SubordinateJTAXAResourceOrphanFilter.

Hope that clarifies,

Tom