Sounds like a useful change. You should be able to introduce a setter that takes a java.util.concurrent.ThreadFactory which defaults to Executors.defaultThreadFactory but in wildfly the transactions subsystem passes in the managed version (javax.enterprise.concurrent.ManagedThreadFactory)

I agree, I don't think is actually too invasive a change as the PeriodicRecovery class is internal. I have a small prototype that is actually very small:

Misfire sorry!

The commit is this: PeriodicRecovery as Runnable · jbosstm/narayana@04ade78 · GitHub

As you can see, its not configurable atm but what Mike proposes should be possible. It does look like we would lose the ability to name the thread unless I am missing something in the API? This would not be ideal but the benefit of being able to resolve from JNDI in the JEE environment would outweigh it for me.

As you can see, its not configurable atm but what Mike proposes should be possible. It does look like we would lose the ability to name the thread unless I am missing something in the API?

We could still have named threads in the standalone case since we can provide our own ThreadFactory implementation that does the thread naming. But yes I agree that would not work when running inside an app server.

I don't think the API of threadfactory newThread provides a name param - unless we made a threadfactory that creates all threads with "Periodic Recovery" as the name? I am not too keen on that one but as you suggest it would keep the current behavior the closest - at least in standalone mode.

Great - seems like you have all the pieces of the puzzle then

Before changing anything could you please explain why this is "crucial for compensations implementation"?

OK but I don't get how this has anything to do with the PeriodicRecovery Thread implementation. If we are going to make changes to code we need to make sure that we document the reasons as much as possible in case there are issues which come up later and people at that time need to know why we made such changes. I'm not making any comment on whether or why this specific change is needed, I'm talking purely about documenting the initial requirement that kicked off the discussion. You, Mike and Tom may know precisely what you meant, but it's not coming through in your responses so far.

What about the other places where we manage thread creation ourselves (such as asynchronous synchronizations and 2PC end calls). Will these be similarly effected?