Remove High contention on TransactionManager class #4496
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
… causes high contention on TransactionManager class.
The current Narayana integration frequently calls
TransactionalInterceptorBase.invokeInOurTx()
, which looks up the current configured TX timeout via((TransactionManagerImple) com.arjuna.ats.jta.TransactionManager.transactionManager()).getTimeout()
This is a very expensive call, as
com.arjuna.ats.jta.TransactionManager.transactionManager()
is synchronized on thecom.arjuna.ats.jta.TransactionManager
class.We could use the @ApplicationScoped TransationManager injected into io.quarkus.narayana.jta.runtime.interceptor.TransactionalInterceptorBase if the API defined
getTimeout()
, but it does not. At present@inject TransationManager transactionManager
can not be cast toTransactionManagerImple
as it is a proxy.I am not 100% happy with this PR, as it changes the injected bean to an impl bean instead of an api bean, but it does remove the monitor contention under heavy load.
@stuartwdouglas @mkouba can you think of any other way of resolving this issue?