I am trying to understand how the XADataSourceAutoConfiguration relates to the AtomikosJtaConfiguration and more generally the **JtaConfiguration.
More specifically how the two classes below relate to each other:
org.springframework.boot.autoconfigure.jdbc.XADataSourceAutoConfiguration
org.springframework.boot.autoconfigure.transaction.jta.AtomikosJtaConfiguration
I need a spring boot spring batch application to participate in transactions involving two databases.
Can someone please tell me how the two classes relate to each other?
I was not able to find much documentation in the javadocs API or in the reference documentation about XADataSourceAutoConfiguration.
XADataSourceAutoConfiguration is responsible for taking an XADataSource and applying a transaction manager-specific wrapper. That wrapper is how the data source is enlisted in any XA transactions.
AtomikosJtaConfiguration is responsible for configuring Atomikos, including providing the Atomikos-specific XADataSource wrapper that will ensure that Atomikos knows about the XADataSource and enlists it in any XA transactions.
Related
Suppose I have some third party library and I want to integrate it with Spring in order to be able to use it as a part of Spring transaction. I didn't find any relevant information on the Internet and looked into the source code of integrations of RabbitMQ and MyBatis libraries. As I understood from their source code I should implement org.springframework.transaction.PlatformTransactionManager and interact with TransactionSynchronizationManager. And there are two questions:
How Spring "know" about and instanciate implementations of PlatformTransactionManager?
Suppose there are two resources been used in transaction through RabbitTemplate and
JdbcTemplate. What will be first committed - changes in database or
messages sent?
Also, I would be really appreciate if somebody point me out to some guide or book about interactions with Spring internals.
You have to instantiate them yourself, like a DataSourceTransactionManager or a HibernateTransactionManager. Spring Boot does that for you under the hood, but with plain Spring you need to do it yourself.
What you want are distributed transactions (XADataSource), which are not possible with RabbitMQ.
For RabbitMQ you should read this here first: https://www.rabbitmq.com/confirms.html . Then make sure you understand transactions on the JDBC side. Then you can reason about how they both work together.
For the Java side, you might enjoy this book entirely about transactions: https://www.marcobehler.com/books/1-java-database-connections-transactions
What is the point of using spring transaction while we have database level transaction ?
If you use mysql, oracle or any other db in java, they provide methods to make things inside transaction then why spring transaction if I can do transaction using java DB driver methods ?
It's another layer of abstraction over the database transaction API. So if you wanted to use multiple databases with global transactions, Spring would allow you to do this. While I have never done it, I believe it would allow you to use DB2 and Hibernate together, for example.
Generally, what I've found is, if a feature is available in Spring, it's because there is a use case for it. They don't just put things into the framework without a reason.
Also, Spring provides declarative transaction demarcation, which produces more readable and maintainable Java code. The declarative approach lets us change the transaction strategy easily, without changing the code.
The Declarative transaction management approach allows you to manage the transaction with the help of configuration instead of hard coding in your source code. This means that you can separate transaction management from the business code. You only use annotations or XML based configuration to manage the transactions
We used Spring AOP along with Hibernate using this transaction strategy Here is an example, Spring AOP transaction mangement with Hibernate.
I have a spring application which is based on Spring Batch. By default spring batch introduces transaction for its steps (i.e. at reader,writer and processor) . There are certain stages where I don't really need transaction to be enabled. Because transaction is enabled unnecessary for these methods its giving me some runtime errors as I am making call to two different databases in one method.
Is there any annotation which spring provides to DISABLE transaction for a specific set of methods ?
OR is there anything available in spring batch which can allow me to get rid of transaction either completely or declarative
I am even open to the solution which can disable transaction globally.
Any link , paper will greatly be appreciated.
Thanks in advance
Samir
Spring Batch is inherently transactional. Even if your datasources are not transactional, the semantics of the JobRepository require it. The closest you can get with Spring Batch and not being transactional is using the ResourcelessTransactionManager. This transaction manager is essentially a no-op transaction manager that just keeps track of if an operation is within the scope of a transaction or not.
I am a newbie to spring hibernate.
And I find 2 ways to handle transactions in Spring declaratively - ProxyFactoryBean using TransactionInterceptor or the #Transactional annotation.
How do we decide which one to prefer?
Is there any other way available for declarative transaction management too?
Advantages of annotaions way:
Annotations are directly visible in the code.
Advantages of xml way:
You can reuse the same conf between multiple beans
You can share some class between two applications and apply different transaction rules
I prefer annotations where it is possible. It saves a lot of time when you read the code (you do not need open one more file and check it periodically).
Other way for declarative transactions: use <aop:config> with <tx:advice>. See corresponding entry in official documentation. It is a variation of xml way that is more easy to do then ProxyFactoryBean (you do not need to wrap beans / declare transaction interceptor manually).
Hope this helps.
Im working with the Spring Framework 3.0.5 and the Hibernate Framework and Im starting to use now Springs Transactionmanagement. I have some questions, just to understand how Springs Transactionmanagement works.
1)
I read this things in the Spring reference:
a) Consistent programming model across different transaction APIs such as Java Transaction API (JTA), JDBC, Hibernate, Java Persistence API (JPA), and Java Data Objects (JDO).
b) Spring resolves the disadvantages of global and local transactions. It enables application developers to use a consistent programming model in any environment. You write your code once, and it can benefit from different transaction management strategies in different environments.
c) Gone are the days when the only alternative to using EJB CMT or JTA was to write code with local transactions such as those on JDBC connections, and face a hefty rework if you need that code to run within global, container-managed transactions. With the Spring Framework, only some of the bean definitions in your configuration file, rather than your code, need to change.
From a) I understand that I can use those APIs with Spring without changing the code
From b) I understand that I can use global or local transactions *without changing the code
From c) I understand that while switching between different APIs and global/local transactions I need to change the code
Now I wonder what is correct?
=> Do I need to change the code? When switching between different APIs? When switching between local and global transactions? (Or does it maybe depend on prorgammatic and declarative transaction management?)
2)
I also got an additional question: I really wonder what the use of programmatic transaction management is? Everywhere I read that declarative transactionmanagement is recommended
I read this in spring reference too:
d) With programmatic transaction management, developers work with the Spring Framework transaction abstraction, which can run over any underlying transaction infrastructure. With the preferred declarative model, developers typically write little or no code related to transaction management, and hence do not depend on the Spring Framework transaction API, or any other transaction API.
From d) I understand: with programmatic transaction management I can use any underlying transaction infrastructure... which means what? the different APIs mentioned above?
and: with declarative I do not depend on any api
=> isnt this the same? when I can use any underlying api, I do not depend on any api. I do not really understand this.
where is the difference? I only know that the declarative transaction management is more lightweight, that I have not to start the transaction by my self and catch the exception and handle it and so on. But what is the use of programmatic transaction management then?
Thank you for answering! :-)
You're over-thinking this a bit. The Spring API provides an abstract transaction model that has the same API and semantics regardless of which underlying transaction technology you use. In order to switch from one technology to another, you generally have to alter your Spring config, but the idea is that you never needs to to alter your business logic. So whether you're using local, in-VM JDBC transactions or fully distributed, two-phase-commit XA JPA-style transactions, the API usage within your Spring code is the same. Only the configuration changes.
The difference between declarative and programmatic transaction management is that with the former, you use annotations or XML config to say which bits of code are supposed to be transactional. With programmatic style, you specifically enclose transactional logic using method calls into the Spring API. Note that if you use the declarative style, then Spring will wrap your code in generated logic which uses the programmatic style. The latter is simply a more explicit and low-level version of the former. It gives you more control, but it's more verbose.