These are the transaction propagation behaviours defined by the propagation enum. RuntimeExceptions triggers rollback, and any checked Exceptions do not. The default timeout of the underlying transaction system, or to none if timeouts are not supported. Optional array of names of exception classes that must not cause rollback. Optional array of exception classes that must not cause rollback.Īrray of String class names, which must be derived from Throwable.
Optional array of names of exception classes that must cause rollback. Optional array of exception classes that must cause rollback.Īrray of class names. Optional qualifier specifying the transaction manager to be used.Īrray of Class objects, which must be derived from Throwable. The following table from the documentation lists all of them. There are quite a few settings that can be applied to this annotation. For example, “start a brand new read-only transaction when this method is invoked, suspending any existing transaction”. The annotation is metadata that specifies that an interface, class, or method must have transactional semantics. In order to apply transaction management, all you have to do is add the annotation. So, you don’t have to do anything to enable transaction management. because I have spring-data libraries in the classpath, transaction management is enabled by the framework. We are building a Spring Boot application, so most of the configuration is done for me. Typically transaction management is enabled using annotation or it could also be done via XML. This changes following things in our sendReceiveError() method execution: 19:33:43.How To Enable Spring’s Transaction Management class ) public class RabbitConfiguration // However this manager should be explicitly created by the application, what I do together with RabbitAdmin bean (can be used to define queues, exchanges and bidings) and making sure the RabbitTemplate has enabled transactional (EnableRabbit. If there’s no other transactional resources RabbitMQ can be transactional using its own RabbitTransactionManager. from the service with only :spring-boot-starter-amqp dependency. To achieve this I started the development from the service using RabbitMQ, i.e. It’d be nice if this core library could autodetect technologies used by specific service and prepare transaction manager accordingly. I assume some of services will use RabbitMQ only, while other services will use additionally MongoDB and/or PostgreSQL database. Planning the architecture I’ve extracted some java core library, which can be used as a base for all java-based microservices in the application ecosystem. Both of them support transactions and both are supported by PlatformTransactionManager in Spring Framework.
So what we have left is RabbitMQ and Postgres.
But finally I don’t see the requirement of using transaction with mentioned usecases (distrubuted session, cache, etc.). For those much better implementation is provided by Redisson, which does not support transactions. However, Spring support for Redis seems to raw for the usages I’ve been thinking about. Redis on the other hand supports some kind of transactions which is even supported by RedisTemplate in Spring Data. I feel this will finally be a problem in a complex application, but we will skip this technology in this little article. However, from the list above MongoDB doesn’t support transactions at all. Now it’d be nice to have everything working transparently under one transaction manager. The most common choices as always come from Spring-supported technologies and my ones are PostgreSQL and MongoDB as databases (depending on if we need transactional database in the specific service or not), Redis as a distributed memory grid and RabbitMQ for messaging. To create serious web application we need at least a database, something for messaging and distributed session/cache. Doing some proofs of concept for the brand new microservices architecture using Spring Boot and Spring Cloud I’ve chosen few backing technologies for tests.
0 kommentar(er)
