HAKUNAMATATA: [API] JPA

Interface that defines an abstraction for finding and managing JPA PersistenceUnitInfos.
Used by LocalContainerEntityManagerFactoryBean in order to obtain a PersistenceUnitInfo for building a concrete EntityManagerFactory.

Used as internal default by LocalContainerEntityManagerFactoryBean.
Supports standard JPA scanning for persistence.xml files, with configurable file locations, JDBC DataSource lookup and load-time weaving.
The default XML file location is classpath*:META-INF/persistence.xml, scanning for all matching files in the class path (as defined in the JPA specification).
DataSource names are by default interpreted as JNDI names, and no load time weaving is available (which requires weaving to be turned off in the persistence provider).

MessageSource implementation that accesses resource bundles using specified basenames.
This class relies on the underlying JDK's ResourceBundle implementation, in combination with the JDK's standard message parsing provided by MessageFormat.

Servlet 2.3 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 JpaTransactionManager or JtaTransactionManager as well as for non-transactional read-only execution.

Is appropriate for applications that use a single JPA EntityManagerFactory for transactional data access.
JTA (usually through JtaTransactionManager) is necessary for accessing multiple transactional resources within the same transaction.
Note that you need to configure your JPA provider accordingly in order to make it participate in JTA transactions.
Supports direct DataSource access within a transaction (i.e. plain JDBC code working with the same DataSource). This allows for mixing services which access JPA and services which use plain JDBC (without being aware of JPA)!
Application code needs to stick to the same simple Connection lookup pattern as with DataSourceTransactionManager (i.e. DataSourceUtils.getConnection(javax.sql.DataSource) or going through a TransactionAwareDataSourceProxy). Note that this requires a vendor-specific JpaDialect to be configured.
Will autodetect the DataSource used as known connection factory of the EntityManagerFactory, so you usually don't need to explicitly specify the "dataSource" property.

* transaction-type

HAKUNAMATATA