PlatformTransactionManager implementation that orchestrates transaction creation, commits and rollbacks to a
list of delegates. Using this implementation assumes that errors causing a transaction rollback will usually happen
before the transaction completion or during the commit of the most inner
The configured instances will start transactions in the order given and commit/rollback in reverse order,
which means the
PlatformTransactionManager most likely to break the transaction should be the last
in the list configured. A
PlatformTransactionManager throwing an exception during commit will automatically
cause the remaining transaction managers to roll back instead of committing.
As consequence, a transaction can get into a state, where the first
PlatformTransactionManager has committed
its transaction and a subsequent
PlatformTransactionManager failed to commit its transaction (e.g. caused by
an I/O error or the transactional resource failed to commit for other reasons). In that case,
commit(TransactionStatus) throws a
HeuristicCompletionException to indicate a partially committed
transaction. Rollback isn't affected as the natural consequence of a missing commit is a rollback of a transactional
ChainedTransactionManager should be only used if the application can tolerate or recover from
inconsistent state caused by partially committed transactions. In any other case, the use of
ChainedTransactionManager is not recommended.
Instead of using
ChainedTransactionManager for attaching callbacks to transaction commit (pre commit/post
commit), either register a
TransactionSynchronization to explicitly
follow transaction cleanup with simplified semantics in case of exceptions.
transactionManagers- must not be null or empty.
getTransactionpublic org.springframework.data.transaction.MultiTransactionStatus getTransaction
(@Nullable TransactionDefinition definition) throws TransactionExceptionDeprecated.