Paul Robinson wrote:
David,
My current thoughts are that we can get classloading to do most of the heavy-lifting here and prevent too-much disruption of the Narayana code-base. Are you able to take a look at the "Overview of the solution" section and let me know if you think I am heading in the right direction? I suspect the main problem would be that we are simplifying the development work at the cost of performance and memory footprint due to there being two TMs running.
Thanks,
Paul.
The solution is not what I'd call "elegant". It does introduce duplication, which is annoying (at best) for packagers and at least theoretically problematic if the two coordinatores ever interact in any way, and doesn't scale well (especially if we want to start supporting multiple transaction management configurations). It is what I would call a "short term hack" - it'll solve our short term problem well enough, but it is very unlikely that these efforts will be usefully reusable in any other context.
Honestly the structure of the code is very archaic in this regard. While I appreciate and respect the very conservative approach that the team has historically taken with things like this, I feel that modernizing the code base is still the best move because it addresses many likely use cases without a particularly high level of complexity, and also without wandering down any seldom-trod architectural paths (i.e. componentizing on a POJO basis is a very well-established, safe practice, whereas relying on global state has many known weaknesses relative to this).
But, that is just my recommendation, and I recognize that my perspective is quite different from yours and that my recommendation goes beyond our actual concrete requirements, so take it as advice and not any kind of mandate.