Can we use the fallback method to reverse the transaction? Are there any disadvantages of it? Or is it fine?
Related
Usual org.springframework.data.redis.core.RedisTemplate have that multi() method, which allow to start a transaction and exec() to commit.
But org.springframework.data.redis.core.ReactiveRedisTemplate does not have that methods.
I searched a lot for an any way on how to use transaction with spring-boot-starter-data-redis-reactive and i found no solutions.
The only way i see it now is manualy create Lettuce Client Bean and use it along side Spring implementation. But that is not handy to have 2 separate redis clients.
Does anyone know how to use redis transaction with spring-boot-starter-data-redis-reactive? could you please write a simple example?
I have some service method used in my controller endpoint whose logic is not fully executed when connectivity issues arise (as you would expect). I am looking for a potential approach, rather than using a try and catch block within the service method. What is the recommended way to go? Is there any "rollback" functionality that can be injected in Spring whereby if something happens during the executing of the service logic then it rolls back?
Thank you
Why is Spring KafkaTemplate implemented in an asynchronous way? Do we have any other Spring implementation of it that is synchronous? I don't want to use futureTask.get() to make is seem synchronous
You probably miss the fact that Spring for Apache Kafka is nothing more than convenient Spring-friendly API around standard Kafka Client. And that's already a Producer.send() API to return for us a Future making all the stack as asynchronous. So, even if someone would do a synchronous API for you it still would do that futureTask.get() underneath.
I'm new to spring, started using spring boot for the project. We have an use case of implementing database changes and few external API calls as one transaction. Please suggest, is this possible with the spring #transactional?
Do the API calls need to be part of the transaction?
If the answer is no, I would advise to use TransactionTemplate.doInTransaction() leaving the API requests outside of the Tx.
If you need to make the API requests inside a Tx, I would advise against it, you would be locking DB resources for the duration of those requests.
You can also search and find out more about the eventual consistency model.
Using #Transactional for multiple database changes as one transaction is of course doable with the annotation but not so much for the external API calls. You would have to implement some custom logic for that - there would have to be endpoints to undo your last actions and you would have to implement calling them manually in try-catch block for example. For example, if the external API call creates an item there would also have to be an endpoint to delete an item and so on.
So to summarise - using #Transactional annotation for implementing database changes as one transaction is fine, but not enough for external API calls.
Is there an easy/lightweight way to add persistence to Spring's JavaMailSender and have it operate asynchronously? Does Spring provide any "built-in" support for this? I'm currently looking at queues with JMS, but they seem like overkill for the task at hand (looking at ActiveMQ and RabbitMQ). Is there a lightweight JMS option?
Your approach with jms is fine. Unfortunately persistence and asynchronous processing is not such a simple task and you will have to code a bit.
However have a look at Spring integration, it provides built-in support for JMS inbounds and e-mail outbounds - all you have to do is connect the pieces via XML DSL.
If you want to make any method in Spring asynchronous, all you need to do is configure task namespace in the xml config via <task:annotation-driven/>. Then, you just annotate the method with #Async and it will run in its own thread. Note that an async call will run in its own transaction, as Spring grabs a new thread from its internal pool to service the call. If you do this, then you don't need JMS for aynchronous processing.