For implementors, it is recommended to derive from the provided
org.
class, which pre-implements the defined propagation behavior and takes care
of transaction synchronization handling. Subclasses have to implement
template methods for specific states of the underlying transaction,
for example: begin, suspend, resume, commit.
A classic implementation of this strategy interface is
org.. However,
in common single-resource scenarios, Spring's specific transaction managers
for e.g. JDBC, JPA, JMS are preferred choices.
org.springframework.transaction.support.TransactionTemplate , org.springframework.transaction.interceptor.TransactionInterceptor , org.springframework.transaction.ReactiveTransactionManager , ConfigurableTransactionManager
| Modifier and Type | Method and Description |
|---|---|
| public void | commit(TransactionStatus
object returned by the status)getTransaction methodCommit the given transaction, with regard to its status. |
| public TransactionStatus | Returns: transaction status object representing the new or current transactionthe TransactionDefinition instance (can be definition)null for defaults),
describing propagation behavior, isolation level, timeout etc.Return a currently active transaction or create a new one, according to the specified propagation behavior. |
| public void | rollback(TransactionStatus
object returned by the status)getTransaction methodPerform a rollback of the given transaction. |
| commit | back to summary |
|---|---|
| public void commit(TransactionStatus status) throws TransactionException Commit the given transaction, with regard to its status. If the transaction has been marked rollback-only programmatically, perform a rollback. If the transaction wasn't a new one, omit the commit for proper participation in the surrounding transaction. If a previous transaction has been suspended to be able to create a new one, resume the previous transaction after committing the new one. Note that when the commit call completes, no matter if normally or throwing an exception, the transaction must be fully completed and cleaned up. No rollback call should be expected in such a case. Depending on the concrete transaction manager setup,
| |
| getTransaction | back to summary |
|---|---|
| public TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException Return a currently active transaction or create a new one, according to the specified propagation behavior. Note that parameters like isolation level or timeout will only be applied to new transactions, and thus be ignored when participating in active ones. Furthermore, not all transaction definition settings will be supported by every transaction manager: A proper transaction manager implementation should throw an exception when unsupported settings are encountered. An exception to the above rule is the read-only flag, which should be ignored if no explicit read-only mode is supported. Essentially, the read-only flag is just a hint for potential optimization.
| |
| rollback | back to summary |
|---|---|
| public void rollback(TransactionStatus status) throws TransactionException Perform a rollback of the given transaction. If the transaction wasn't a new one, just set it rollback-only for proper participation in the surrounding transaction. If a previous transaction has been suspended to be able to create a new one, resume the previous transaction after rolling back the new one. Do not call rollback on a transaction if commit threw an exception. The transaction will already have been completed and cleaned up when commit returns, even in case of a commit exception. Consequently, a rollback call after commit failure will lead to an IllegalTransactionStateException. Depending on the concrete transaction manager setup,
| |