spring-framework / org.springframework.orm.jpa.support

Package org.springframework.orm.jpa.support

Types

OpenEntityManagerInViewFilter

open class OpenEntityManagerInViewFilter : OncePerRequestFilter

Servlet Filter that binds a JPA EntityManager to the thread for the entire processing of the request. Intended for the "Open EntityManager in View" pattern, i.e. to allow for lazy loading in web views despite the original transactions already being completed.

This filter makes JPA EntityManagers available via the current thread, which will be autodetected by transaction managers. It is suitable for service layer transactions via org.springframework.orm.jpa.JpaTransactionManager or org.springframework.transaction.jta.JtaTransactionManager as well as for non-transactional read-only execution.

Looks up the EntityManagerFactory in Spring's root web application context. Supports an "entityManagerFactoryBeanName" filter init-param in web.xml; the default bean name is "entityManagerFactory". As an alternative, the "persistenceUnitName" init-param allows for retrieval by logical unit name (as specified in persistence.xml).

OpenEntityManagerInViewInterceptor

open class OpenEntityManagerInViewInterceptor : EntityManagerFactoryAccessor, AsyncWebRequestInterceptor

Spring web request interceptor that binds a JPA EntityManager to the thread for the entire processing of the request. Intended for the "Open EntityManager in View" pattern, i.e. to allow for lazy loading in web views despite the original transactions already being completed.

This interceptor makes JPA EntityManagers available via the current thread, which will be autodetected by transaction managers. It is suitable for service layer transactions via org.springframework.orm.jpa.JpaTransactionManager or org.springframework.transaction.jta.JtaTransactionManager as well as for non-transactional read-only execution.

In contrast to OpenEntityManagerInViewFilter, this interceptor is set up in a Spring application context and can thus take advantage of bean wiring.

PersistenceAnnotationBeanPostProcessor

open class PersistenceAnnotationBeanPostProcessor : InstantiationAwareBeanPostProcessor, DestructionAwareBeanPostProcessor, MergedBeanDefinitionPostProcessor, PriorityOrdered, BeanFactoryAware, Serializable

BeanPostProcessor that processes javax.persistence.PersistenceUnit and javax.persistence.PersistenceContext annotations, for injection of the corresponding JPA resources javax.persistence.EntityManagerFactory and javax.persistence.EntityManager. Any such annotated fields or methods in any Spring-managed object will automatically be injected.

This post-processor will inject sub-interfaces of EntityManagerFactory and EntityManager if the annotated fields or methods are declared as such. The actual type will be verified early, with the exception of a shared ("transactional") EntityManager reference, where type mismatches might be detected as late as on the first actual invocation.

Note: In the present implementation, PersistenceAnnotationBeanPostProcessor only supports @PersistenceUnit and @PersistenceContext with the "unitName" attribute, or no attribute at all (for the default unit). If those annotations are present with the "name" attribute at the class level, they will simply be ignored, since those only serve as deployment hint (as per the Java EE specification).

This post-processor can either obtain EntityManagerFactory beans defined in the Spring application context (the default), or obtain EntityManagerFactory references from JNDI ("persistence unit references"). In the bean case, the persistence unit name will be matched against the actual deployed unit, with the bean name used as fallback unit name if no deployed name found. Typically, Spring's org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean will be used for setting up such EntityManagerFactory beans. Alternatively, such beans may also be obtained from JNDI, e.g. using the jee:jndi-lookup XML configuration element (with the bean name matching the requested unit name). In both cases, the post-processor definition will look as simple as this:

 <bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"/>
In the JNDI case, specify the corresponding JNDI names in this post-processor's "persistenceUnits" map, typically with matching persistence-unit-ref entries in the Java EE deployment descriptor. By default, those names are considered as resource references (according to the Java EE resource-ref convention), located underneath the "java:comp/env/" namespace. For example:
 <bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"> <property name="persistenceUnits"> <map/gt; <entry key="unit1" value="persistence/unit1"/> <entry key="unit2" value="persistence/unit2"/> </map/gt; </property> </bean>
In this case, the specified persistence units will always be resolved in JNDI rather than as Spring-defined beans. The entire persistence unit deployment, including the weaving of persistent classes, is then up to the Java EE server. Persistence contexts (i.e. EntityManager references) will be built based on those server-provided EntityManagerFactory references, using Spring's own transaction synchronization facilities for transactional EntityManager handling (typically with Spring's @Transactional annotation for demarcation and org.springframework.transaction.jta.JtaTransactionManager as backend).

If you prefer the Java EE server's own EntityManager handling, specify entries in this post-processor's "persistenceContexts" map (or "extendedPersistenceContexts" map, typically with matching persistence-context-ref entries in the Java EE deployment descriptor. For example:

 <bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"> <property name="persistenceContexts"> <map/gt; <entry key="unit1" value="persistence/context1"/> <entry key="unit2" value="persistence/context2"/> </map/gt; </property> </bean>
If the application only obtains EntityManager references in the first place, this is all you need to specify. If you need EntityManagerFactory references as well, specify entries for both "persistenceUnits" and "persistenceContexts", pointing to matching JNDI locations.

NOTE: In general, do not inject EXTENDED EntityManagers into STATELESS beans, i.e. do not use @PersistenceContext with type EXTENDED in Spring beans defined with scope 'singleton' (Spring's default scope). Extended EntityManagers are not thread-safe, hence they must not be used in concurrently accessed beans (which Spring-managed singletons usually are).

Note: A default PersistenceAnnotationBeanPostProcessor will be registered by the "context:annotation-config" and "context:component-scan" XML tags. Remove or turn off the default annotation configuration there if you intend to specify a custom PersistenceAnnotationBeanPostProcessor bean definition.

SharedEntityManagerBean

open class SharedEntityManagerBean : EntityManagerFactoryAccessor, FactoryBean<EntityManager>, InitializingBean

FactoryBean that exposes a shared JPA javax.persistence.EntityManager reference for a given EntityManagerFactory. Typically used for an EntityManagerFactory created by org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean, as direct alternative to a JNDI lookup for a Java EE server's EntityManager reference.

The shared EntityManager will behave just like an EntityManager fetched from an application server's JNDI environment, as defined by the JPA specification. It will delegate all calls to the current transactional EntityManager, if any; otherwise, it will fall back to a newly created EntityManager per operation.

Can be passed to DAOs that expect a shared EntityManager reference rather than an EntityManagerFactory. Note that Spring's org.springframework.orm.jpa.JpaTransactionManager always needs an EntityManagerFactory in order to create new transactional EntityManager instances.