When upgrading from Spring Boot 2.2.9 to 2.3.0, unit tests cannot handle large datasets anymore.

When logging with a debug level, we see extShutdownHook drops tables before the end of the insertions, hence the test fails.

Here is a minimal reproducible example : it works with 2.2.9, but when upgrading to 2.3.0 we can see 10k rows seems too much.

The problem still exist in the last version (2.3.2).

Comment From: snicoll

Thanks for the report and the sample. Ignoring that the project does not compile because it uses JUnit4 and the vintage engine has been excluded, I can run the test and it passes when I removed the exclusion.

Given that your example works for me, you'll have to share more details about your environment (OS, JDK). Attaching the logs of the execution (either as a file or on gist.github.com) would be helpful as well.

Comment From: wikisamuel

Thanks for the reply. Maybe your computer is just faster than mine and you should try with a larger dataset. I've uploaded a new version with 20k rows so you can test.

Here are the logs I've just had.

I'm using Windows 10 Enterprise 1909 18363.900 and JDK 11.0.7+10.

Comment From: snicoll

That is interesting, thanks. Spring Boot 2.3 has switched the JPA bootstrap mode to deferred and it might be causing an issue for you. To confirm this and provide you a temporary workaround if it does, can you please add spring.data.jpa.repositories.bootstrap-mode=default to your configuration to see if that problem goes away?

Comment From: rohitrajt

I have the same problem. In my case, the unit tests works fine in 2.3.0. We have been running with 2.3.0 for quite some time now without any issues. Today, when i upgrade to 2.3.2 i see the same error as mentioned in this issue. Also I tried the solution provided by @snicoll and it still has the same issue.

I also confirmed that my unit test context starts with DEFAULT bootstrap mode, [ Test worker] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data JPA repositories in DEFAULT mode.

Comment From: wikisamuel

The workaround provided by @snicoll has worked for me! Thanks!

Comment From: snicoll

@rohitrajt I am not sure that you have the same problem, especially given that @wikisamuel has confirmed the workaround work for them. To figure it out and help you, please open a separate issue with a small sample that works with 2.3.0 and breaks with 2.3.2 (a zip or a link to a GitHub repo). Thanks!

Comment From: snicoll

So that's our basic datasource init friend again. https://github.com/spring-projects/spring-boot/blob/ac357283a639a7709d20a2fae2b0af0e99daaf3d/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/orm/jpa/DataSourceInitializedPublisher.java#L195-L202) when JPA is in place is done using the right callback but that doesn't seem to work.

I am not entirely sure if that's a framework limitation or our (rather convoluted) arrangement.

Comment From: snicoll

According to @jhoeller we shouldn't invoke the bootstrapExecutor ourselves. If we fire the event directly, the execution will be part of the lock so that might fix that issue. I need to figure out why the bootstrapExecutor was used manually first.

Comment From: snicoll

Relates to #14061

Comment From: snicoll

Unfortunately, we can't switch to this as I thought as we send an event in that EMF lock and that leads to a deadlock in framework .

Comment From: snicoll

I've created https://github.com/spring-projects/spring-framework/issues/25799