public interface TransactionSynchronization
extends java.io.Flushable
TransactionSynchronization implementations can implement the Ordered interface to influence their execution order. A synchronization that does not implement the Ordered interface is appended to the end of the synchronization chain.
System synchronizations performed by Spring itself use specific order values, allowing for fine-grained interaction with their execution order (if necessary).
TransactionSynchronizationManager
,
AbstractPlatformTransactionManager
,
DataSourceUtils.CONNECTION_SYNCHRONIZATION_ORDER
Modifier and Type | Field and Description |
---|---|
static int |
STATUS_COMMITTED
Completion status in case of proper commit.
|
static int |
STATUS_ROLLED_BACK
Completion status in case of proper rollback.
|
static int |
STATUS_UNKNOWN
Completion status in case of heuristic mixed completion or system errors.
|
Modifier and Type | Method and Description |
---|---|
default void |
afterCommit()
Invoked after transaction commit.
|
default void |
afterCompletion(int status)
Invoked after transaction commit/rollback.
|
default void |
beforeCommit(boolean readOnly)
Invoked before transaction commit (before "beforeCompletion").
|
default void |
beforeCompletion()
Invoked before transaction commit/rollback.
|
default void |
flush()
Flush the underlying session to the datastore, if applicable:
for example, a Hibernate/JPA session.
|
default void |
resume()
Resume this synchronization.
|
default void |
suspend()
Suspend this synchronization.
|
static final int STATUS_COMMITTED
static final int STATUS_ROLLED_BACK
static final int STATUS_UNKNOWN
default void suspend()
default void resume()
default void flush()
flush
in interface java.io.Flushable
TransactionStatus.flush()
default void beforeCommit(boolean readOnly)
This callback does not mean that the transaction will actually be committed. A rollback decision can still occur after this method has been called. This callback is rather meant to perform work that's only relevant if a commit still has a chance to happen, such as flushing SQL statements to the database.
Note that exceptions will get propagated to the commit caller and cause a rollback of the transaction.
readOnly
- whether the transaction is defined as read-only transactionjava.lang.RuntimeException
- in case of errors; will be propagated to the caller
(note: do not throw TransactionException subclasses here!)beforeCompletion()
default void beforeCompletion()
This method will be invoked after beforeCommit
, even when
beforeCommit
threw an exception. This callback allows for
closing resources before transaction completion, for any outcome.
java.lang.RuntimeException
- in case of errors; will be logged but not propagated
(note: do not throw TransactionException subclasses here!)beforeCommit(boolean)
,
afterCompletion(int)
default void afterCommit()
Can e.g. commit further operations that are supposed to follow on a successful commit of the main transaction, like confirmation messages or emails.
NOTE: The transaction will have been committed already, but the
transactional resources might still be active and accessible. As a consequence,
any data access code triggered at this point will still "participate" in the
original transaction, allowing to perform some cleanup (with no commit following
anymore!), unless it explicitly declares that it needs to run in a separate
transaction. Hence: Use PROPAGATION_REQUIRES_NEW
for any
transactional operation that is called from here.
java.lang.RuntimeException
- in case of errors; will be propagated to the caller
(note: do not throw TransactionException subclasses here!)default void afterCompletion(int status)
NOTE: The transaction will have been committed or rolled back already,
but the transactional resources might still be active and accessible. As a
consequence, any data access code triggered at this point will still "participate"
in the original transaction, allowing to perform some cleanup (with no commit
following anymore!), unless it explicitly declares that it needs to run in a
separate transaction. Hence: Use PROPAGATION_REQUIRES_NEW
for any transactional operation that is called from here.
status
- completion status according to the STATUS_*
constantsjava.lang.RuntimeException
- in case of errors; will be logged but not propagated
(note: do not throw TransactionException subclasses here!)STATUS_COMMITTED
,
STATUS_ROLLED_BACK
,
STATUS_UNKNOWN
,
beforeCompletion()