|
|
|
@ -268,10 +268,17 @@ The actual JPA provider bootstrapping is handed off to the specified executor an |
|
|
|
running in parallel, to the application bootstrap thread. The exposed `EntityManagerFactory` |
|
|
|
running in parallel, to the application bootstrap thread. The exposed `EntityManagerFactory` |
|
|
|
proxy can be injected into other application components and is even able to respond to |
|
|
|
proxy can be injected into other application components and is even able to respond to |
|
|
|
`EntityManagerFactoryInfo` configuration inspection. However, once the actual JPA provider |
|
|
|
`EntityManagerFactoryInfo` configuration inspection. However, once the actual JPA provider |
|
|
|
is being accessed by other components (for example, calling `createEntityManager`), those calls |
|
|
|
is being accessed by other components (for example, calling `createEntityManager`), those |
|
|
|
block until the background bootstrapping has completed. In particular, when you use |
|
|
|
calls block until the background bootstrapping has completed. In particular, when you use |
|
|
|
Spring Data JPA, make sure to set up deferred bootstrapping for its repositories as well. |
|
|
|
Spring Data JPA, make sure to set up deferred bootstrapping for its repositories as well. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
As of 6.2, JPA initialization is enforced before context refresh completion, waiting for |
|
|
|
|
|
|
|
asynchronous bootstrapping to complete by then. This makes the availability of the fully |
|
|
|
|
|
|
|
initialized database infrastructure predictable and allows for custom post-initialization |
|
|
|
|
|
|
|
logic in `ContextRefreshedEvent` listeners etc. Putting such application-level database |
|
|
|
|
|
|
|
initialization into `@PostConstruct` methods or the like is not recommended; this is |
|
|
|
|
|
|
|
better placed in `Lifecycle.start` (if applicable) or a `ContextRefreshedEvent` listener. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[[orm-jpa-dao]] |
|
|
|
[[orm-jpa-dao]] |
|
|
|
== Implementing DAOs Based on JPA: `EntityManagerFactory` and `EntityManager` |
|
|
|
== Implementing DAOs Based on JPA: `EntityManagerFactory` and `EntityManager` |
|
|
|
@ -284,9 +291,9 @@ to a newly created `EntityManager` per operation, in effect making its usage thr |
|
|
|
|
|
|
|
|
|
|
|
It is possible to write code against the plain JPA without any Spring dependencies, by |
|
|
|
It is possible to write code against the plain JPA without any Spring dependencies, by |
|
|
|
using an injected `EntityManagerFactory` or `EntityManager`. Spring can understand the |
|
|
|
using an injected `EntityManagerFactory` or `EntityManager`. Spring can understand the |
|
|
|
`@PersistenceUnit` and `@PersistenceContext` annotations both at the field and the method level |
|
|
|
`@PersistenceUnit` and `@PersistenceContext` annotations both at the field and the method |
|
|
|
if a `PersistenceAnnotationBeanPostProcessor` is enabled. The following example shows a plain |
|
|
|
level if a `PersistenceAnnotationBeanPostProcessor` is enabled. The following example |
|
|
|
JPA DAO implementation that uses the `@PersistenceUnit` annotation: |
|
|
|
shows a plain JPA DAO implementation that uses the `@PersistenceUnit` annotation: |
|
|
|
|
|
|
|
|
|
|
|
[tabs] |
|
|
|
[tabs] |
|
|
|
====== |
|
|
|
====== |
|
|
|
|