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.
This transaction manager also 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
or going through a
Note that this requires a vendor-specific JpaDialect to be configured.
Note: To be able to register a DataSource's Connection for plain JDBC code,
this instance needs to be aware of the DataSource ( setDataSource(DataSource) ).
The given DataSource should obviously match the one used by the given
EntityManagerFactory. This transaction manager will autodetect the DataSource
used as known connection factory of the EntityManagerFactory, so you usually
don't need to explicitly specify the "dataSource" property.
On JDBC 3.0, this transaction manager supports nested transactions via JDBC 3.0
Savepoints. The setNestedTransactionAllowed(boolean) "nestedTransactionAllowed"}
flag defaults to "false", though, as nested transactions will just apply to the
JDBC Connection, not to the JPA EntityManager and its cached objects.
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.