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.
Didn't we relax that a couple of years ago? I know that way back we had the idea of the AS as a protective host running many applications that were potentially hostile towards the AS (and which could even be potentially hostile to each other).
Much of the awkwardness of the early security APIs also came from that idea. But over time we let that idea go, and only old-world APIs still occasionally stick to it.
Ludo said this about the topic btw:
"I don’t get why there is such separation between applications and app servers. Why would programmers writing business applications wouldn’t be authorized to suspend and resume transactions? I guess the original intent was with EJB only in mind but event then, EJBs can be configured with Bean Managed Transactions maybe since 1.0, certainly since 2.0. Why application programmers weren’t allowed to use this API, required to implement the REQUIRES_NEW transaction demarcation by suspending the active transaction before starting a new one?"
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.
Indeed, but exactly that imprisonment idea has been let go I think. With Jakarta EE runtimes (fat jars, and such) and specifically docker containers we don't really need this anymore? Look e.g. at what CDI extensions can do, and how there is no distinction between App Server level APIs and User Level APIs or such.
Kind regards,
Arjan Tijms
