Make use of Spring 4.3 background Hibernate initialization

[philwebb]

See https://jira.spring.io/browse/SPR-13732 - We need #5082 first

[snicoll]

We need to have our generally purpose AsyncTaskExecutor first (see #5082).

[snicoll]

If the user has defined an AsyncTaskExecutor that is primary, maybe we should automatically enable that feature. Thoughts?

[vpavic]

Hey @snicoll, I did some work on addressing this and was about to create a PR when I saw you've recently assigned the issue to yourself.

My changes are available here, let me know if I should go ahead with the PR. Thanks.

[snicoll]

Closing in favour of PR #7184

[philwebb]

We'll need to do some profiling with a typical Spring Data application. The last time I tried background initialization I found the Spring Data almost immediately caused a wait as it obtained meta-data.

[ptahchiev]

I have a project with more than 200 entities with Spring Data Repositories. App starts in 60 seconds and I'm really curious to see if this will improve the startup time. Let me know if you want me to test.

[odrotbohm]

I guess it's worth referencing the discussion I had with Jürgen on the original ticket. The tl;dr is that unless we significantly change the way Spring Data JPA verifies repositories — and by that basically throw some of the fundamental traits of the bean lifecycle (e.g. a bean is fully initialized as soon as it's injected) — you'll hardly see any benefits here as the Spring Data bootstrap is accessing an EntityManager for validation purposes pretty early.

[odrotbohm]

To summarize my concerns here: the only way to let the parallel initialization shine through is by delaying repository validation significantly. That can cause unexpected effects that might cause more harm than good especially in production systems.

You can actually get this to work right now already simply annotating all repository injection points with @Lazy as that's basically the annotation based equivalent to an ObjectFactory<FooRepository> with transparent lookup. That would cause the repositories to be actually initialized (read: validated) on first usage. That however might (will?) run inside a transaction. Unfortunately, part of the query method validation is the attempt to find a named query and JPA in turn throws an exception in case of the absence of such, which in turn again will have to cause the transaction to roll back. That'll lead to a first request to an application to fail, while subsequent ones will succeed. Depending on which requests actually use which repository that symptom might be seen multiple times. Quite a nightmare to discover, debug etc.

In a different case — still undecided whether worse or not — you'll bootstrap an app that doesn't work at all and while previously the app would've not even started it now runs but without a way to indicate it's actually broken. It just serves 500s all over the place.

That said, I can completely see the benefits of being able to bootstrap Hibernate while let's say Spring MVC is already booting. I just think it requires quite a bit of care when to implicitly activate that feature. I guess the DevTools seem to be a good candidate for that. Eventually forcing the initialization by deploying an ApplicationListener to listen for an application start event, could mitigate the problems, too.

[ptahchiev]

Hello,

I personally would love to see a global setting (perhaps a spring-boot property) to enable/disable such lazy loading globally for all repositories. I would probably leave the lazy-loading off during development, but have it on when deployed to production. The reason for that is that we want to have autoscaling on production environments and we want to have new instances spinned up as fast as possible when the traffic/memory usage/cpu usage increases. It makes sense to have this property off during development to ease the debugging. However, it makes more sense to have such global property on in production - where the software has already been tested and there won't be any repository validation errors, or missing named JPA queries.

[odrotbohm]

That's interesting because so far I've only heard the completely opposite story: people want things to (re)bootstrap incredibly fast during development but don't care so much about production startup times as they happen way less often and are often fronted by a system already running.

Also, exposing the mode in production would always leave that option of starting something that's not working. I'd argue that's worse than doing so in development.

[odrotbohm]

I've played with this a little again and I feel like it's a tricky thing to get right in user code already. Just making sure that all repository references are basically delayed proxies is not a trivial task in a non-trivial codebase. Just missing one completely wrecks the effort. Also, everything that uses @PersistenceContext and thus Spring's PersistenceAnnotationBeanPostProcessor is basically screwed, too as this will cause the blocking call to EMF.createEntityManager(…) via SharedEntityManagerCreator.

So I guess without proper tools to diagnose what's preventing the asynchronous bootstrap mode from actually taking effect it's much easier to just fight with it trying to get it to work.

[snicoll]

We're cleaning out the issue tracker and closing issues that we've not seen much demand to fix. Feel free to comment with additional justifications if you feel that this one should not have been closed.

[odrotbohm]

Just to ping the interested parties about some development made for #13833. Spring Data JPA is going to ship support for deferred repository initialization in Lovelace. There's a working example to be found here. #13833 is taking care of easing the activation of those modes for Boot apps.