Develop Reference

Spring transaction management: Scope of annotations and default behaviours

I am basically trying to understand transaction management in spring. When we use #Transactional annotation with a method, does spring call all it's sub-functions also within the same transaction?
In a scenario where you have used #Transactional and your sub-function throws a DB Exception, if you have not explicitly mentioned rollback, what happens? (If you have mentioned rollback in sub-function, I believe the entire transaction is reverted, please correct me if I am wrong). How is transaction management handled without any annotations (does spring create a new transaction for each DB call?) And finally, are all these behaviours same for
javax.transaction.Transactional
and for
org.springframework.transaction.annotation.Transactional
?
I have been reading resources on the same, but am confused about these base concepts. I am trying to clarify them else I might learn them wrong. Could somebody please help?
Thank you in advance.

Spring boot declarative transaction management

I am working on an application written in Spring-Boot and JPA, the application has started from scratch. So I am thinking of introducing transaction management in it. There is entity and service layer in the application. Right now what I am thinking is that to go with Spring declarative transaction management. So, I have decided to put the #Transaction annotation on the top of the service layer itself as shown below, please advise is there any best approach to do the same also please make a note that I am using spring-boot-starter-data-jpa dependency itself
#Transactional
public class UserService {
}

Question is a bit too general, but your way of thinking is one of the standard and acceptable ways to work with declarative transaction management. I usually though do it per service method. This way you can specify if transaction is read only and some other parameters per particular service method which I think is more flexible.

It's not quite clear what your question is; do you just want someone to tell you that your approach is valid?
When you design a Spring application with a layered architecture, it is common to have the transaction boundaries on the service layer. The service layer then uses Spring Data repositories (which are in the data access layer). Your approach, where you use #Transaction annotations on the service layer, is a common way of doing this. So you are on the right track.

Spring self injection for transactions

In Spring you can't simply call #Transactional method from the same instance, because of AOP-proxy thing. Would it be nice idea to make a self injection and call that method from self proxy instance? Do you see any drawbacks?

It is totally ok.
Moreover there was a Jira ticket for supporting this feature using #Autowired annotations. It's fixed in Spring 4.3+ versions. However for xml-based configuration or using #Resource annotation it's working in the earlier versions.
You can see the discussion bellow this ticket. #Transactional is one of the use case for this:
Particularly interested in #Async and #Transactional use cases.

Spring-free Hibernate DAO and #Repository for Exception translation! Isn't that dependency?

I've read that the new way of creating Hibernate DAO is using Hibernate contextual sessions. The main reason being to avoid the Spring based HibernateTemplate/HiberateDaoSupport and thus Spring-Free DAO.
When I searched what to do with Exception translation? It's written everywhere that I should use #Repository! #Repository does need import and creates dependencies in my code. Am I right?
Aren't annotations considered dependency? If they are, is there anyway I can have that using XML? Or should I use the old HibernateDaoSupport way, since I'm going to have my code coupled with Spring anyway?
Update
Found a similar question: "integrate hibernate with spring without spring dependency in dao" but:
The first paragraph of the answer that #pap has given does not specify any clear XML alternative for #Repository.
The insight offered in the rest of that answer is plausible, yet my question remains unanswered that if decoupling is not much of a concern, why did Spring try proposing the new approach to Hibernate DAO?
P.S. This is not a criticism. It's rather an attempt to learn the proper way of thinking about this topic (i.e. the dependency).

The point of Spring exception translation in the first place is to break a dependency on Hibernate by creating a dependency on Spring. Regardless of the annotation, Spring exception translation catches a Hibernate exception and turns it into a Spring exception. By putting catch statements in your code tied to the Spring exception you are coupling your code to Spring far more directly than by adding any #Repository annotations. If you don't want to depend on Spring then simply use the Hibernate exceptions directly. Basically, there are two approaches:
Use Hibernate for exceptions and contextual sessions (no coupling to Spring). In this case, simply don't use Spring exception translation at all.
Use Spring for exceptions and session handling (looser coupling to Hibernate, additional coupling to Spring).

Hibernate + Spring using multiple datasources?

I'm working on a web application that uses Spring MVC 2.5 and Hibernate.
One of the requirements of the application is that it must be able to export some objects to an external database. I figure I might as well use my existing data layer and just save the objects to the external source.
I'm new to Spring and Hibernate, and I guess I'm just wondering how I should approach this. Right now everything is automatically wired up through annotations. I'm guessing I'll have to create a new dataSource bean, and a new sessionFactory, and a transactionManager...maybe...but...
I only want the connection to the external data source to be available when the user is specifically "exporting".
Is autowiring going to get in my way? How can I tell Spring to inject the appropriate sessionFactory when I instantiate a DAO for my export process? (I'm autowiring through constructors) Should I programatically create my session factory (etc) and then manually instantiate my DAO? If so, will this "override" the autowire annotation?
I guess I don't need answers to the above questions specifically if someone can just step me through the basic process of getting something like this to work. Thanks!

Spring fortunately already has a solution for this: AbstractRoutingDataSource. It basically acts as a Facade for multiple DataSources and allows you to subclass it and implement whatever logic you need to decide which DataSource should be used. Some details are here:
http://blog.springsource.com/2007/01/23/dynamic-datasource-routing/
This allows your DataSource lookup logic to be handled in exactly one place. Your DAO layer and SessionFactory do not need to be adjusted, except that you need to inject your subclass of AbstractRoutingDataSource into the Hibernate SessionFactory.

Configuring multiple data sources and session factories in your spring context will not itself be a problem, but it does make autowiring less attractive.
You could use the #Qualifier annotation to tell the autowiring which one to choose, but I'd suggest not using autowiring, and instead explicitly injecting the correct data source and session factory using <property> or <constructor-arg>.
The transaction manager could potentially be shared between both data sources, if both data sources are managed by your app server, but it sounds like having transactional integrity across both data sources is not a requirement for you, and that having separate transactions for each data source would be enough.