How to handle transaction using spring boot and cosmosdb. For example write has to made in mutiple collections, if anyone of them fails then all should be rolled back. It is written in this link that its possible with version 4 api.
How to handle Transaction in CosmosDB - "All or nothing" concept
Any integration example will be helpful.
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'm having small e-commerce application with Spring boot, but I want to realtime the rest endpoint where the products are listed, so I want the rest endpoint to be updated if any product is updated or created.
I'm confused how to listen database in realtime. I found Sse for realtime data sending but i couldn't found how to do this with database
Can you please suggest a best methodology
If you are using Hibernate for managing Data. then use hibernate envers and process the model after create/update db.
my suggestion is whenever an action create/update happens in hibernate.
Hibernate envers will trigger and use Akka actor to process the event.
Hibernate -> hibernate Envers -> Akka (business layer) -> rest endpoint
Thanks,
Vimalesh
In Spring based application, Transaction Manager is responsible for committing or rolling back SQL transactions.
My application uses a custom cache for some part of persistent data.
This cache is not managed by Spring nor Hibernate.
If a SQL transaction encounters errors and must be rolled back, then cache modifications should be rolled back as well.
My question is, how to register an event listener or callback which will call my cache.evict() method when Spring Transaction Manager rolls back a transaction?
You can use TransactionSynchronizationAdapter for this. For reference, you can look at this: Spring - commit JMS Transaction after JPA transaction
In the answer given in the link, the synchronization is registered for afterCommit. In your case, it would be afterCompletion. In that implementation, you will need to check if the transaction is in a rolled back state and do the cache eviction.
There are lots of ways of doing this...
You can use application events if you want... Application Events in Spring Framework 4.2
You can throw a custom runtime exception and you can handle it in your exception handler (if you're using spring MVC). but here I don't recommend to do any important operations like clearing of cache here... Exception handling in Spring MVC
You can use a combination of #1 and #2. You can send an event that will eventually throw a runtime exception that you handle it in UI (spring mvc or whatever you use). This is how I would do it
You can throw an exception and anyone calling your bean will get the custom transaction exception you want and will have to deal with notification... I don't recommend this
I have got an application which has got non transactional code.
Currently in Java 6 and Spring 2.5.6 ( use ibatis-sqlmap-2.3.0).
The requirement is that while processing an enterprise service bean message if a database outage happens the transaction should be rolled back and puts the message back into queue.
What changes should I make can you please give me a pointer ?
You can use Two Face Commits to integrate Spring with JMS and a database. We use Atomikos as a transaction manager. Have a look at http://www.atomikos.com/Documentation/TwoPhaseCommitWithTomcatSpringJMSAndJDBC .
You should consider upgrading your Spring Project. Spring 3.2.x is the lowest supported version.
I'm using Oracle 11g for my database and its Oracle Streams AQ feature as JMS implementation.
For all I know, it should be possible to implement a Spring based message-driven POJO (MDP) that uses the same data source for both transactional data access and JMS transactions -- all without XA-Transactions (IIRC, this was marketed as a feature of SpringSource Advanced Pack for Oracle).
Is this possible using Hibernate as well? Ideally, my MDP would start a JMS transaction and read a message from a queue, then re-use the transaction for data access through Hibernate. If anything goes wrong, the JMS and database transaction would both be rolled back, without using 2-phase commit (2PC).
I'm not much of a transaction guru, so before I start digging deeper, can anyone confirm that this is possible and makes sense as well?
Update:
What I want is an implementation of the Shared Transaction Resource pattern. The sample code demonstrates it for ActiveMQ and JDBC, but I need to use Oracle Streams AQ and Hibernate.
Update2:
The SpringSource Advanced Pack for Oracle has been open sourced as part of Spring Data JDBC and it "provides the option of using a single local transaction manager for both
database and message access without resorting to expensive distributed 2-phase commit
transaction management".
2PC shouldn't be necessary, as you say, since the appserver should take care of it. However, you'll pretty much have to use JTA (i.e. JavaEE container) transactions, rather than vanilla DataSource transactions, since JMS only works with JTA.
This isn't a big deal, it's just a bit more fiddly:
Your Spring config should use
<jee:jndi-lookup/> to get a
reference to your container's
DataSource, and you inject that
data source into your spring-managed
hibernate SessionFactory.
You then need to introduce a transaction manager into the context (<tx:jta-transaction-manager/> should work in most app-servers).
In your Spring JMS MessageListenerContainer, plug the above transaction manager reference into it.
Does that all make sense, or should I elaborate? This setup should ensure that the container-managed transactions are held across JMS and Hibernate interactions.