1 of 1 people found this helpful
At this time, we haven't seen enough community demand to work on providing a more complete solution to this than our current approach which is to utilize classloader isolation of the instances.
Please can you elaborate on your requirements and we can try to work with you on it?
We have an application that has a high demand of low end-to-end latency and I was assuming that a transaction manager like Narayana is another synchronization point, which according to Amdahl's law would reduce throughput. Therefore I was planning to do some real performance tests with the two scenarios of one time only using one transaction manager and one time using a transaction manager per unit of work. The different transaction managers could even write to different disks to further reduce the latency.
Many thanks for your answer.
Are you aware if any of the other open source transaction managers allow for many transaction managers in the same JVM?
You're assuming that there is one transaction manager for all transactions within Narayana. That is an incorrect assumption. Whilst we may talk about THE transaction manager, in reality every transaction is handled by a unique coordinator instance.
As Mark says above, each transaction has its own coordinator instance. So for example you can instantiate the following class and use it (or the BasicAction they derive from):
Here is an example of our unit tests doing that:
The issue I can foresee is that you may eventually want to have different configurations for each transaction concurrently (you talk about configuring each transaction to use a different disk). To do that you will need to use classloader isolation like I have here (and related classes):
Perfect! That is what I am looking for. Thanks!
No problem - good luck with your testing!