When you call a method without @Transactional within a transaction block, the parent transaction will continue to the new method. It will use the same connection from the parent method (with @Transactional) and any exception caused in the called method (without @Transactional) will cause the transaction to rollback as configured in the transaction definition. If … Read more
No, methodB() will not be executed in the same transaction as methodA(). Spring’s @Transactional only works on a single thread – it creates a session when a thread first enteres a method with @Transactional (or a method in a class with @Transactional), and then commits it when it leaves that method. In your example, the … Read more
Please note that since Spring 4.3.1, ReflectionTestUtils should automatically unwrap proxies. So ReflectionTestUtils.setField(validationService, “countryService”, countryService); should now work even if your countryService is annotated with @Transactional, @Cacheable… (that is, hidden behind a proxy at runtime) Related issue: SPR-14050
in your log4j.properties (for alternative loggers, or log4j’s xml format, check the docs) Depending on your transaction manager, you can set the logging level of the spring framework so that it gives you more info about transactions. For example, in case of using JpaTransactionManager, you set log4j.logger.org.springframework.orm.jpa=INFO (this is the package of the your transaction … Read more
Because hibernate will automatically detect changes made to persistent entities and update the database accordingly. This behaviour is documented in chapter 11 of the hibernate reference manual. The relevant part reads: Hibernate defines and supports the following object states: Transient – an object is transient if it has just been instantiated using the new operator, … Read more
The reason that moving the context:component-scan tags to the application context xml fixed the transactional behavior is: <tx:annotation-driven /> is a post-processor that wraps @Transactional annotated bean methods with an AOP method interceptor which handles transactional behavior. Spring post-processors, only operate on the specific application context they are defined in. In your case, you have … Read more
TLDR: this is because only the service layer in the application has the logic needed to identify the scope of a database/business transaction. The controller and persistence layer by design can’t/shouldn’t know the scope of a transaction. The controller can be made @Transactional, but indeed it’s a common recommendation to only make the service layer … Read more
Good question, although not a trivial one to answer. Propagation Defines how transactions relate to each other. Common options: REQUIRED: Code will always run in a transaction. Creates a new transaction or reuses one if available. REQUIRES_NEW: Code will always run in a new transaction. Suspends the current transaction if one exists. The default value … Read more
This is a big topic. The Spring reference doc devotes multiple chapters to it. I recommend reading the ones on Aspect-Oriented Programming and Transactions, as Spring’s declarative transaction support uses AOP at its foundation. But at a very high level, Spring creates proxies for classes that declare @Transactional on the class itself or on members. … Read more