spring-boot
spring-boot copied to clipboard
spring-projects
Breaking change of transaction autoconfiguration in 2.7.6
Spring Boot 2.7.6 introduced a breaking change in the autoconfiguration order/priority, which makes it behave differently to 2.7.5. More precisely, the JdbcTransactionAutoconfiguration/DataSourceTransactionManager precedence was changed.
In our case, the JdbcTransactionAutoconfiguration is initialized in 2.7.6, but 2.7.5 initializes JpaTransactionAutoconfiguration.
I think a patch version should not introduce a potentially breaking change like this.
This change was probably introduced here: https://github.com/spring-projects/spring-boot/commit/4bb13bcdfd5af5f33841e9f53055e4b2fd5d59aa
Having just migrated from 2.7.3 to 3.0.0 some of my integration tests are now failing due to database isolation issues, despite @Transactional being on the test class.
I suspect this issue might be the cause of the difference.
My Integration test declares the following in this order:
@SpringBootTest
@AutoConfigureTestDatabase
@AutoConfigureDataJpa
@AutoConfigureTestEntityManager
@EnableAutoConfiguration
@EnableJpaAuditing
@EntityScan
@EnableJpaRepositories
@ComponentScan
@Transactional
Whereas before the Integration tests worked, they now fail with index failures on inserts - which has been caused by a failure to rollback the transaction properly between tests.
Perhaps this is related? If so this also has an implication for 3.0.0.
I think I have reached in the same issue, some integration tests are failing because from tests I try to delete some data and than call endpoint.
The data after deletion is still there even though the method is annotated with @Transactional(propagation = Propagation.REQUIRES_NEW).
The method does not fail so no exception happens but it looks like the change is not committed.
Did you discover any workaround?
A workaround would be manual transaction manager initialization.
Over the time, I was trying to figure out the repro steps, but I was not successful. It just happens only with some of our projects (also with the current 2.7.8), and I do not know why, unfortunately.
Unfortunately, I've been unable to figure out why the described problem would happen. I agree that https://github.com/spring-projects/spring-boot/commit/4bb13bcdfd5af5f33841e9f53055e4b2fd5d59aa is the most likely cause but the changes look OK to me as AutoConfigurationSorter treats a before relationship from A -> B as an after relationship from B -> A.
The behavior of the sorter should be deterministic so it's interesting that it "happens only with some of our projects". My working theory at the moment is that those projects don't all have the same set of auto-configuration classes on the classpath. In some cases the auto-configuration that is present somehow affects the ordering and triggers the bug.
@vlastikcz, if you can reproduce the problem in one of your affected projects, could you please debug AutoConfigurationSorter and let us know the list of class names that is passed into getInPriorityOrder(Collection<String>)? If some of those classes are not part of Spring Boot itself, details of their auto-configuration ordering (@AutoConfigureOrder, @AutoConfigureBefore, and @AutoConfigureAfter) would also be useful.
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.
In our case, the issue was caused by a custom autoconfiguration:
@ConditionalOnBean(PlatformTransactionManager.class)
@AutoConfiguration(after = TransactionAutoConfiguration.class)
public class CustomAutoConfiguration {
We had to add @AutoConfigureOrder(Ordered.LOWEST_PRECEDENCE) to this class, and everything is back to normal.