for a single JPA EntityManagerFactory. Binds a JPA
EntityManager from the specified factory to the thread, potentially allowing for
one thread-bound EntityManager per factory. SharedEntityManagerCreator and
@PersistenceContext are aware of thread-bound entity managers and participate
in such transactions automatically. Using either is required for JPA access code
supporting this transaction management mechanism.
This transaction manager 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.
Note: To be able to register a DataSource's Connection for plain JDBC code,
this instance needs to be aware of the DataSource (setDataSource(javax.sql.DataSource)).
The given DataSource should obviously match the one used by the given
EntityManagerFactory. This transaction manager will autodetect the DataSource
used as the connection factory of the EntityManagerFactory, so you usually
don't need to explicitly specify the "dataSource" property.
This transaction manager supports nested transactions via JDBC 3.0 Savepoints.
The "nestedTransactionAllowed" flag defaults
to false though, since nested transactions will just apply to the JDBC
Connection, not to the JPA EntityManager and its cached entity objects and related
context. You can manually set the flag to true if you want to use nested
transactions for JDBC access code which participates in JPA transactions (provided
that your JDBC driver supports Savepoints). Note that JPA itself does not support
nested transactions! Hence, do not expect JPA access code to semantically
participate in a nested transaction.
Set the EntityManagerFactory that this instance should manage transactions for.
Alternatively, specify the persistence unit name of the target EntityManagerFactory.
By default, a default EntityManagerFactory will be retrieved by finding a
single unique bean of type EntityManagerFactory in the containing BeanFactory.
java.lang.IllegalStateException - in case of no EntityManagerFactory set
public void setPersistenceUnitName(@Nullable
Set the name of the persistence unit to manage transactions for.
This is an alternative to specifying the EntityManagerFactory by direct reference,
resolving it by its persistence unit name instead. If no EntityManagerFactory and
no persistence unit name have been specified, a default EntityManagerFactory will
be retrieved by finding a single unique bean of type EntityManagerFactory.
public java.util.Map<java.lang.String,java.lang.Object> getJpaPropertyMap()
Allow Map access to the JPA properties to be passed to the persistence
provider, with the option to add or override specific entries.
Useful for specifying entries directly, for example via "jpaPropertyMap[myKey]".
public void setDataSource(@Nullable
Set the JDBC DataSource that this instance should manage transactions for.
The DataSource should match the one used by the JPA EntityManagerFactory:
for example, you could specify the same JNDI DataSource for both.
If the EntityManagerFactory uses a known DataSource as its connection factory,
the DataSource will be autodetected: You can still explicitly specify the
DataSource, but you don't need to in this case.
A transactional JDBC Connection for this DataSource will be provided to
application code accessing this DataSource directly via DataSourceUtils
or JdbcTemplate. The Connection will be taken from the JPA EntityManager.
Note that you need to use a JPA dialect for a specific JPA implementation
to allow for exposing JPA transactions as JDBC transactions.
The DataSource specified here should be the target DataSource to manage
transactions for, not a TransactionAwareDataSourceProxy. Only data access
code may work with TransactionAwareDataSourceProxy, while the transaction
manager needs to work on the underlying target DataSource. If there's
nevertheless a TransactionAwareDataSourceProxy passed in, it will be
unwrapped to extract its target DataSource.
Return a transaction object for the current transaction state.
The returned object will usually be specific to the concrete transaction
manager implementation, carrying corresponding transaction state in a
modifiable fashion. This object will be passed into the other template
methods (e.g. doBegin and doCommit), either directly or as part of a
The returned object should contain information about any existing
transaction, that is, a transaction that has already started before the
current getTransaction call on the transaction manager.
Consequently, a doGetTransaction implementation will usually
look for an existing transaction and store corresponding state in the
returned transaction object.
Check if the given transaction object indicates an existing transaction
(that is, a transaction which has already started).
The result will be evaluated according to the specified propagation
behavior for the new transaction. An existing transaction might get
suspended (in case of PROPAGATION_REQUIRES_NEW), or the new transaction
might participate in the existing one (in case of PROPAGATION_REQUIRED).
The default implementation returns false, assuming that
participating in existing transactions is generally not supported.
Subclasses are of course encouraged to provide such support.
Begin a new transaction with semantics according to the given transaction
definition. Does not have to care about applying the propagation behavior,
as this has already been handled by this abstract manager.
This method gets called when the transaction manager has decided to actually
start a new transaction. Either there wasn't any transaction before, or the
previous transaction has been suspended.
A special scenario is a nested transaction without savepoint: If
useSavepointForNestedTransaction() returns "false", this method
will be called to start a nested transaction when necessary. In such a context,
there will be an active transaction: The implementation of this method has
to detect this and start an appropriate nested transaction.
Perform an actual commit of the given transaction.
An implementation does not need to check the "new transaction" flag
or the rollback-only flag; this will already have been handled before.
Usually, a straight commit will be performed on the transaction object
contained in the passed-in status.
Perform an actual rollback of the given transaction.
An implementation does not need to check the "new transaction" flag;
this will already have been handled before. Usually, a straight rollback
will be performed on the transaction object contained in the passed-in status.
Set the given transaction rollback-only. Only called on rollback
if the current transaction participates in an existing one.
The default implementation throws an IllegalTransactionStateException,
assuming that participating in existing transactions is generally not
supported. Subclasses are of course encouraged to provide such support.