Shulou(Shulou.com)06/01 Report--

This article mainly explains "how to use JTA in Spring Boot2". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to use JTA in Spring Boot2".

Using JTA to handle distributed transactions

Spring Boot supports distributed JTA transactions across multiple XA resources through Atomkos or Bitronix's embedded transaction manager, as well as JTA transactions when deployed to the appropriate J2EE application server.

When a JTA environment is discovered, Spring Boot uses Spring's JtaTransactionManager to manage transactions. Automatically configured JMS,DataSource and JPA beans will be upgraded to support XA transactions. You can use standard Spring idioms, such as @ Transactional, to participate in a distributed transaction. If you are in a JTA environment but still want to use local transactions, you can disable JTA autoconfiguration by setting the spring.jta.enabled property to false.

Use the Atomikos transaction manager

Atomikos is a very popular open source transaction manager and can be embedded in your Spring Boot application. You can use spring-boot-starter-jta-atomikosStarter to get the correct Atomikos library. Spring Boot automatically configures Atomikos and applies the appropriate depends-on to your Spring Beans to make sure they start and shut down in the correct order.

By default, the Atomikos transaction log will be recorded in the transaction-logs folder under the application home directory (the directory where your application jar files are placed). You can define this directory in the application.properties file by setting the spring.jta.log-dir property. The generic performance that begins with spring.jta.atomikos.properties is used to define the UserTransactionServiceIml implementation of Atomikos. For more information, please refer to AtomikosProperties javadoc.

Be careful

To ensure that multiple transaction managers can safely cooperate with the corresponding resource managers, each Atomikos instance must set up a unique ID. By default, this ID is the IP address on the machine on which the Atomikos instance is running. To ensure the uniqueness of the ID in a production environment, you need to set a different spring.jta.transaction-manager-id property value for each instance of the application.

Use the Bitronix transaction manager

Bitronix is a popular open source JTA transaction manager implementation, and you can use spring-boot-starter-jta-bitronixstarter to add appropriate Birtronix dependencies to your project. Like Atomikos, Spring Boot automatically configures Bitronix and post-process the beans to ensure that they start and shut down in the correct order.

By default, Bitronix transaction logs (part1.btm and part2.btm) will be recorded in the transaction-logs folder under the application home directory, which you can customize by setting the spring.jta.log-dir property. Properties that start with spring.jta.bitronix.properties will be bound to bitronix.tm.Configuration bean, where you can make further customizations, as shown in the Bitronix documentation.

Be careful

To ensure that multiple transaction managers can safely cooperate with the corresponding resource managers, each Bitronix instance must set up a unique ID. By default, this ID is the IP address on the machine on which the Bitronix instance is running. To ensure the uniqueness of the ID in a production environment, you need to set a different spring.jta.transaction-manager-id property value for each instance of the application.

Use the Narayana transaction manager

Narayana is a popular open source JTA transaction manager implementation that is currently only supported by JBoss. You can use spring-boot-starter-jta-narayana starter to add appropriate Narayana dependencies, like Atomikos and Bitronix, Spring Boot will automatically configure Narayana and post-process your beans post-processing to ensure proper startup and shutdown.

The Narayana transaction log is recorded by default in the transaction-logs directory of the application home directory (the directory where the application jar is placed). You can customize this directory by setting the spring.jta.log-dir attribute in application.properties. Attributes that start with spring.jta.narayana.properties can be used to customize the Narayana configuration, see NarayanaProperties.

Be careful

To ensure that the multi-transaction manager can safely cooperate with the corresponding resource manager, each Narayana instance must be configured with a unique ID, with the default ID set to 1. To ensure the uniqueness of ID in a production environment, you can configure different spring.jta.transaction-manager-id property values for each instance of the application.

Using a transaction manager managed by J2EE

If you package the Spring Boot application as a war or ear file and deploy it to an J2EE application server, you can use the transaction manager built into the application server. Spring Boot will try to automatically configure a transaction manager by looking for common JNDI paths (java:comp/UserTransaction, java:comp/TransactionManager, etc.). If you use the transactional services provided by the application server, you usually need to make sure that all resources are managed by the application server and exposed through JNDI. Spring Boot automatically configures JMS by looking for the JNDI path java:/JmsXA or java:/XAConnectionFactory to get a ConnectionFactory, and you can configure your DataSource using the spring.datasource.jndi-name attribute.

JMS connection with mixed XA and non-XA

When using JTA, primary JMS ConnectionFactorybean will be able to recognize XA and participate in distributed transactions. In some cases, you may need to use non-XA 's ConnectionFactory to process some JMS messages. For example, your JMS processing logic may have a longer timeout than XA.

If you want to use a non-XA ConnectionFactory, you can inject nonXaJmsConnectionFactory bean instead of @ Primary jmsConnectionFactory bean. To maintain consistency, jmsConnectionFactory bean will be used under the alias xaJmsConnectionFactor.

Examples are as follows:

1max / Inject the primary (XA aware) ConnectionFactory

2@Autowired

3private ConnectionFactory defaultConnectionFactory

4max / Inject the XA aware ConnectionFactory (uses the alias and injects the same as above)

5@Autowired

6@Qualifier ("xaJmsConnectionFactory")

7private ConnectionFactory xaConnectionFactory

8// Inject the non-XA aware ConnectionFactory

9@Autowired

10@Qualifier ("nonXaJmsConnectionFactory")

11private ConnectionFactory nonXaConnectionFactory

Support for alternative embedded transaction managers

The XAConnectionFactoryWrapper and XADataSourceWrapper interfaces are used to support replaceable embedded transaction managers. This interface is used to wrap XAConnectionFactory and XADataSource beans and expose them as normal ConnectionFactory and DataSource beans so that they can be used transparently in distributed transactions. Spring Boot will automatically configure your DataSource and JMS with the appropriate XA wrapper and JtaTransactionManager bean registered with ApplicationContext.

BitronixXAConnectionFactoryWrapper and BitronixXADataSourceWrapper provide a good example of how to write an XA wrapper.

Thank you for your reading, the above is the content of "how to use Spring Boot2 JTA", after the study of this article, I believe you have a deeper understanding of how to use Spring Boot2 JTA, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.