Starting up a Spring Data JPA application requires an
EntityManagerFactory to be bootstrapped.
This usually consumes quite a bit of the startup time of the application overall.
To tackle this problem, Spring Framework already introduced the ability to bootstrap that
EntityManagerFactory in a background thread and, thus, let other beans get initialized in parallel.
Unfortunately, Spring Data repositories usually have at least one transitive dependency on some kind of Spring bean.
Their initialization, in turn, interacts with the factory already, which — without further steps — caused the initialization of those other components to block.
This limited the effect of that new functionality significantly.
As of Spring Data Lovelace, you can now define the repositories to bootstrap in a lazy mode, which automatically declares all injection points of Spring Data repositories as being lazy.
This causes Spring Framework to create proxies and delay the actual repository initialization up until the very first interaction with them.
In other words, repositories clients and clients of those clients can, in turn, be created without having to wait for the
EntityManagerFactory to finish its bootstrap.
That means that a significantly higher amount of Spring bean initialization can be parallelized to the JPA bootstrap.
The delay of the initialization also causes any kind of verification to be delayed until (for example) the very first request that hits the code path that actually uses a repository.
If you want to still make sure that the repositories are fully initialized before the application starts taking requests, use the deferred bootstrap mode.
This mode works in the same way as the lazy one, except that, when the container is done bootstrapping, it explicitly triggers the initialization of all repositories in the
The easiest way to switch between those modes is by setting the Spring Boot properties
spring.jpa.repositories.bootstrap-mode to either
This also ensures that the lazy initialization of the
EntityManagerFactory is configured properly.
Also, be sure to check out the new section added to the reference documentation.
We have prepared an example to show the effect of that optimization in a quite extreme example consisting of 2,000 entities, 2,000 repositories and 2,000 beans that depend on the repositories.
Using the deferred mode cuts off about a third (~12 seconds) of the startup time.
The lazy one even takes away another third (~22 seconds better than the default).