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.
Related
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.
TLDR:
1.Where does atomikos keep its trasnaction records so it can function and how is it best to "secure" them against losing/corrupting them. I use Docker/Docker-Compose and Spring Boot.
2.If the app dies unexpectdly, do all the transactions roll back because atomikos automagically started the appropiate SQL/JMS transactions with the sources?
Details
Hello.
I am starting to use atomikos in Spring Boot to enable XA transactions (in my case simply one datasource and an ActiveMQ/JMS broker.
I have been Googling and can't find a more "in depth" blog or site that explains in a bit more details how Atomikos works under the hood.
I do see the atomikos transaction logs in the form:
{"id":"127.0.1.1.tm159765570032300035","wasCommitted":true,"participants":[{"uri":"127.0.1.1.tm35","state":"COMMITTING","expires":1597655710327,"resourceName":"dataSource"},{"uri":"127.0.1.1.tm36","state":"COMMITTING","expires":1597655710327,"resourceName":"jmsConnectionFactory"}]}
I can only assume these are simply actual "logs" and not like the kafka.db file in say ActiveMQ when using file persistence.
Questions
So does atomikos keep its state in memory?
If say an unexpected shutdown occurred half way through an XA transaction, will all the JTA sources simply rollback?
If the atomikos state is held in a file/database somewhere...are there some best practices when using docker-compose for example?
Example:
A #Component picks out a database entity "REQUIRES_PROCESSING" for queuing on to a JMS queue and then switches the entity to "PROCESSING".
The JMS message is queued but then the App unexpectedly dies before the database entity is set to "PROCESSING".
Will in this case, atomikos has now no state (it died with the app) but it created a SQL and ActiveMQ trasnaction that will simply timeout and everything rolls back?
The application reboots 5 seconds later...what happens here? Is this transaction picked up again somehow (i.e. atomikos has still got state somewhere?).
Will the rebooted app just grab the rolledback entity and simply retry as expected?
Are there any pitfalls here?
Thank you for any claification.
Here is the flow:
Begin Transaction.
Message put into the queue but not ready to be dequeue. (Right now I don't know how to achieve it)
(i)End Transaction - Successful: Message will be available to be dequeue.
(ii) Rollback: Message will be removed from queue.
Message successfully de-queue by the Listener.
I can configure Spring Transaction Manager for hibernate entities. Same way I can Active MQ available for JMSTransactionManager. But the big question is How would JMSTransactionManager will know the state of HibernateTransactionManager? How would these two interact?
Note: I am using Tomcat managed datasources for Hibernate entities. Apache Camel support is also available in project.
You need an XA-enabled transaction manager, and Spring doesn't come with any. So either deploy your app in a Java EE application server, or embed a stand-alone transaction manager like Bitronix.
I am not running under Java EE.
I want to have an XA transaction using Spring to share a transaction between DB and JMS.
Does spring provide such a functionality or must I use an external transaction manager such as Atomikos?
I use currently the DataSourceTransactionManager for the DB, and I see I can also use the JMSTransactionManager. Do they work together? Not clear from the documentation as JtaTransactionManager is mentioned.
Please advise.
Yair
Spring only provides a framework for transaction management, it as such doesn't provide any transaction manager. If you are running your application outside a Java EE container and you need a transaction between resources like a DB and JMS, you have to use an external TransactionManager like Atomikos or JOTM (Java Open Transaction Manager).
You might want to refer to http://www.javaworld.com/javaworld/jw-04-2007/jw-04-xa.html for more details on XA using Spring.
they are resource local, but Spring does support XA (see this post for explanation and example code) : http://blog.springsource.com/2011/08/15/configuring-spring-and-jta-without-full-java-ee/
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.