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.
Related
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.
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.
We are currently using Spring 3.2.3 + JPA (Hibernate). We use aspects for transaction support as opposed to annotations. We write out own entity services (read: repositories) to abstract the persistence away from our application.
I've read a lot about Spring Data and feel it would make our code considerably cleaner and more robust. I wonder though, are there any gotchas that I should consider before transitioning?
Thanks
If you're already on JPA the transition should be as easy as it can be: activate the repositories, point the infrastructure to your EntityManagerFactoryBean and off you go.
Transactions should just work fine as well. The annotation based usage within Spring Data is selectively activated for the repository beans only. They are configured to take part in existing transactions by default, so any custom larger scoped transaction setting should be in effect already.
I want to implement transaction using Spring's transaction management feature. But I'm not sure which is better(AOP vs #Transactional). Do both features work correctly? Is there any difference in development efficiency?
(Added)
Here AOP means "using AspectJ without using #Transactional annotation explicitly"
(Added)
I want to know difference of annotation-config and XML-based configuration
I've wondered this myself. I found a good discussion of this topic on the Spring forum.
Below I've summarize my take from the aforementioned link:
AOP Transactional Demarcation
Benefits:
Java code is devoid of transaction configuration which is contained instead outside of the code in configuration files
Java code has no direct dependencies on Spring libraries
Transaction management is centralized in one place
Can apply transactional boundaries to source code you can't easily modify
Drawbacks:
AOP complexity. It will not be clear from the code alone where transactional boundaries lie and developers may inadvertently break transactions by, for example, modifying method signatures where a pointcut is applied
The need to touch two locations (source code and AOP configuration) in order to apply transactional boundaries
#Transactional Spring annotation
Benefits:
Transactional boundaries are more clearly understood when examining the source code
Drawbacks:
Java code is coupled with transaction declaration (albeit only at the metadata level, but still a Spring import is required).
The discussion reminds me of JPA annotations versus JPA XML configuration. With XML based JPA configuration, entities are "cleaner", but is the separation worth the effort? Or perhaps even, is the separation harmful (it's nice to be able to open a java source file and know immediately based on the #Entity annotation that the class is an EJB)? In practice, it seems to me that most developers opt to use JPA annotations. Although, in this case unlike #Transactional, jpa annotations are a standard so that may help ease some concerns.
That said, I've been involved on projects were we've used Spring's AOP configuration to annotate a Struts2 (webwork) interceptor to allow a single transaction per request and this worked out great. In this case, we didn't really worry about transactional boundaries in our service layer or elsewhere -- everything was already participating in a transaction and since the view rendered before the interceptor closed the transaction, there was no need to apply an OpenSession/EntityManagerInView solution.
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.