On the topic of UserTransaction/TransactionManager, why do we have both?
My layman's understanding:
As you know, in Java EE (and certain manifestations of Jakarta EE) users can't do fancy things (or anything, really) with threads. Therefore suspending a (definitionally thread-specific) transaction (so that you can start another one? on another thread? oops) probably doesn't make much sense. You also can't do fancy things with files, if you're playing by the rules. So enlisting arbitrary end-user-supplied XAResources in a Transaction seems to run into both restrictions since XAResources by definition may be called in certain cases from different threads, and of course often must do file I/O.
My guess is that it was originally thought that a combination of UserTransaction and TransactionSynchronizationRegistry would give any business user imprisoned in an application server whatever they need to do business work, and deliberately no more.
On the application server side, obviously the ability to enlist XAResources and suspend and resume transactions is critical.
(Is this end-user threading restriction relevant anymore now that we have the "Core Profile" (a.k.a. the cheerfully frenetic unregulated "wild West"; do whatever you want with whatever you bring on any thread however you want to)? I don't know; that all is probably a much larger discussion.)
Best,
Laird
