Why doesnt #Transactional and #RequestMapping work together? - spring

The moment I include the #Transactional annotation on a #RequestMapping, I notice in springboot that the url mappings do not auto-configure.
What could be responsible for this?
I want a case where (C)R(UD) rest calls work within a transaction.

If you're goal is to ensure your CRUD operations happen within a transaction, then using Spring Data JPA, this is done for you by default. Creating a repository interface that extends CrudRepository for example, your query methods will inherently be #Transactional. You can customize the #Transactional attributes by manually annotating a query method on your repository, but this need only be done if you want non default behaviour.
See the Spring Data JPA docs for more details.
http://docs.spring.io/spring-data/jpa/docs/current/reference/html/#transactions

Related

Why do we need to annotate the Service class with #Transactional in Spring Data JPA

In a spring boot app, we have user-defined repository interface that extends JpaRepository.
JpaRepository in turn is has an implementation class SimpleJpaRepository.
SimpleJPARepository has 2 annotations on it
#Transactional
#Repository
So we can skip these 2 annotations on our user-defined repository interface that extends JpaRepository.
Then why do we need to explicitly add #Transactional over service class which is also using our user-defined repository object only?
The point of having the Transactional annotation is so that everything in the annotated method occurs within the same unit of work and either everything succeeds or everything fails. Putting Transactional only on each repository means each repository can have its own transaction, and the second one failing doesn't rollback the first one.
You can have nontransactional methods on a service, or every method so annotating a class as a Service doesn't mean spring can assume everything is transactional.
This is a has vs is problem.
An object can be Transactional, or have a member object that is Transactional.
If the object has a member object that is Transactional, it is not automatically Transactional itself.
Object A contains Object B which is Transactional, that does not make Object A Transactional.

Transaction - Springboot(JHipster) - RestService: how to

I have a microservice created with JHipster(SpringBoot+JPA) exposing a rest api.
During a save operation over an Entity I need to manage the transaction because I must execute another update over the DB (using other Entities).
How can I do this?
Using the tradictional approach (JDBC) I got the connection and create a transaction over it, make all the queries and finally close the transaction(commit/rollback).
With JPA I have an Entity, but I find no way to specify to begin/end(manage) the transaction programmatically.
You have many alternatives, here are few ones:
define a service (a class annotated with #Service) and annotate with #Transactional the public method that implements your logic
manage transaction manually through the EntityManager injected into your service class constructor
create a custom Repository
Check the Spring docs

Where to use #Transactional annotation and #Repository annotation

Some of the examples on internet use #Transactional annotation on DAO implementation methods while some use this annotation for the service layer methods. Where is it more appropriate to put the #Transactional and why?
Similarly where to put #Repository annotation. On the DAO interface or on the DAO implementation?
I have always used #Service and #Repository annotations on their implementations, but they can be put in either one. Although, putting it on a interface would mean that you won't be able to have more than one implementation, because you would get a NoUniqueBeanDefinitionException error.
In the case of #Transactional, it depends, but normally it goes on the service. If you want to be able to add various DB calls on one transaction, then it should go in the service. If you want to make small transactions, then on the DAO would be best, but then, you wouldn't be able to modify several tables in one single transaction. Another con of having it on the DAO, is that you won't be able to rollback multiple modifications, only the ones that are bing executed by the DAO.
EDIT
After several projects using Spring, each one of different proportions, I end up changing my own practices. I would like to add that even though adding #Transactional to the service layer isn't exactly bad practice, it can be negatively affect the performance of the application. So in my own experience, it is better to add it to the DAO/Repository layers and only add at function level in the service layer, if a transaction must be atomic.
One more thing, if you are using Spring Data, the #Repository must be added on the interface. Only if you extend the JpaRepository will you need to add the #Repository annotation on the implementation. In this case, the interface of the JpaRepository and the custom implementation will both have #Repository.

omit transactions for specific methods in spring

I'm using the #Transactional annotation for my entire Dao class with spring and hibernate. Everything works great, it's just that I would like to omit the behaviour for a few non database related methods in my Dao.
http://static.springsource.org/spring/docs/2.5.4/reference/transaction.html#transaction-declarative-annotations
Every time I step into these methods during a debugging session, I always get to JdkDynamicAopProxy.class which is super annoying.
Is there any way to omit transactional for specific methods? Or at least fix this annoying debugging behavior?
In Spring you can put the #Transactional annotation on only the methods you want to make transactional, instead of putting it at the class level.
Otherwise perhaps consider extracting those specific non-transactional methods into a separate class?

Mule 3.3 spring 3.1 hibernate 3.6 transaction management

I am working on an application which involves mule, spring, hibernate with annotations. I am using org.springframework.orm.hibernate3.HibernateTransactionManager. Now the problem is :
I have certain components in mule which logs data into db based on conditions using hibernate. I have used #Transactional which inserts few data and then commits the transaction when the method scope is completed. But the behaviour which i want is : first component inserts data based on some condition, but the transaction should not commit immediately, again my second component that is a java class should insert some data again then third etc. if any of the component fails all the queries executed in all the components should be rolled back. all of this components are separate java classes
How can i achieve such behaviour.
thank you,
Let your whole component execution chain be in a transaction. then it will meet your expectation. it is easy to do it if all your components are in the same one spring appliction context. In the case, there are two things you need to do:
Add #Transactional annotation on your component class or specific methods which need to be in transaction. By default, transactional method use REQUIRED Propagation setting which will let all method in the exection chain merge to only one transaction.
Make sure Spring can scan all your components.
#Transactional
#Component( "lbsProviderApiCallJob" )
public class LbsProviderApiCallJoImpl implements LbsProviderApiCallJob, ApplicationContextAware {
If all your component are not in a spring context. it is complex to make it.

Resources