We configure our Spring transaction in Spring config as:
<tx:jta-transaction-manager/>
I gather this means that Spring will automatically discover the underlying JTA implementation. So when we start up JBoss we see these messages while Spring searches:
[JtaTransactionManager] [ ] No JTA TransactionManager found at fallback JNDI location [java:comp/Tran
sactionManager]
javax.naming.NameNotFoundException: TransactionManager not bound
<<Big stack trace>>
<<More of the same>>
And then eventually see:
[JtaTransactionManager] [ ] JTA TransactionManager found at fallback JNDI location [java:/Transaction
Manager]
[JtaTransactionManager] [ ] Using JTA UserTransaction: org.jboss.tm.usertx.client.ServerVMClientUserT
ransaction@1f78dde
Question is - how can we edit our <tx:jta-transaction-manager/>
tag to explicitly configure the java:/Transaction Manager
JTA implementation so we avoid all these stack traces in the logs? (I'd prefer not to just change the Log4J logging levels)
Update: I replaced <tx:jta-transaction-manager/>
with the below config and it seems to work.. i'm guessing this is alright?
<bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager">
<property name="transactionManagerName" value="java:/TransactionManager"/>
</bean>
PlatformTransactionManager implementations are defined like any other object (or bean) in the Spring Framework IoC container. This benefit alone makes Spring Framework transactions a worthwhile abstraction even when you work with JTA. Transactional code can be tested much more easily than if it used JTA directly.
At a high level, Spring creates proxies for all the classes annotated with @Transactional, either on the class or on any of the methods. The proxy allows the framework to inject transactional logic before and after the running method, mainly for starting and committing the transaction.
Spring Boot supports distributed JTA transactions across multiple XA resources by using either an Atomikos or Bitronix embedded transaction manager. JTA transactions are also supported when deploying to a suitable Java EE Application Server.
The Java Transaction API (JTA) is one of the Java Enterprise Edition (Java EE) APIs allowing distributed transactions to be done across multiple XA resources in a Java environment.
Yes, that's alright. The stack trace you were seeing was also alright: <tx:jta-transaction-manager/>
tries to acquire the transaction manager from a number of different standard locations; for every failed JNDI lookup, you'll see the javax.naming.NameNotFoundException
.
java:/TransactionManager
is where JBoss binds to by default; other servlet containers will default to java:/comp/TransactionManager
, which I think is supposed to be the "standard" location for the TM.
From the Spring reference documentation:
For standard scenarios, including WebLogic, WebSphere and OC4J, consider using the convenient
<tx:jta-transaction-manager/>
configuration element. This will automatically detect the underlying server and choose the best transaction manager available for the platform. This means that you won't have to configure server-specific adapter classes (as discussed in the following sections) explicitly; they will rather be chosen automatically, with the standardJtaTransactionManager
as default fallback.
A common "mistake" is to bundle things like jta.jar
and/or jbossall-client.jar
in the J2EE component you deploy. Double check please and remove them if this is the case.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With