Package org.springframework.transaction.support

# Interface TransactionSynchronization

All Superinterfaces:
  `Flushable`, `org.springframework.core.Ordered`

All Known Implementing Classes:
  `ResourceHolderSynchronization`, `TransactionSynchronizationAdapter`

public interface TransactionSynchronization extends org.springframework.core.Ordered, Flushable
Interface for transaction synchronization callbacks. Supported by AbstractPlatformTransactionManager.

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).

Implements the `Ordered` interface to enable the execution order of synchronizations to be controlled declaratively. The default `order` is `Ordered.LOWEST_PRECEDENCE`, indicating late execution; return a lower value for earlier execution.

Since:
  02.06.2003
Author:
  Juergen Hoeller
See Also:
  - `TransactionSynchronizationManager`
  - `AbstractPlatformTransactionManager`
  - `org.springframework.jdbc.datasource.DataSourceUtils#CONNECTION_SYNCHRONIZATION_ORDER`

## Field Summary

Fields
Modifier and Type
Field
Description
`static final int`
`STATUS_COMMITTED`
Completion status in case of proper commit.
`static final int`
`STATUS_ROLLED_BACK`
Completion status in case of proper rollback.
`static final int`
`STATUS_UNKNOWN`
Completion status in case of heuristic mixed completion or system errors.

### Fields inherited from interface org.springframework.core.Ordered

`HIGHEST_PRECEDENCE, LOWEST_PRECEDENCE`

## Method Summary

Modifier and Type
Method
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 int`
`getOrder()`
Return the execution order for this transaction synchronization.
`default void`
`resume()`
Resume this synchronization.
`default void`
`savepoint(Object savepoint)`
Invoked on creation of a new savepoint, either when a nested transaction is started against an existing transaction or on a programmatic savepoint via `TransactionStatus`.
`default void`
`savepointRollback(Object savepoint)`
Invoked in case of a rollback to the previously created savepoint.
`default void`
`suspend()`
Suspend this synchronization.

## Field Details

### STATUS_COMMITTED

static final int STATUS_COMMITTED
Completion status in case of proper commit.

See Also:
  - Constant Field Values

### STATUS_ROLLED_BACK

static final int STATUS_ROLLED_BACK
Completion status in case of proper rollback.

See Also:
  - Constant Field Values

### STATUS_UNKNOWN

static final int STATUS_UNKNOWN
Completion status in case of heuristic mixed completion or system errors.

See Also:
  - Constant Field Values

## Method Details

### getOrder

default int getOrder()
Return the execution order for this transaction synchronization.

Default is `Ordered.LOWEST_PRECEDENCE`.

Specified by:
  `getOrder` in interface `org.springframework.core.Ordered`

### suspend

default void suspend()
Suspend this synchronization. Supposed to unbind resources from TransactionSynchronizationManager if managing any.

See Also:
  - `TransactionSynchronizationManager.unbindResource(java.lang.Object)`

### resume

default void resume()
Resume this synchronization. Supposed to rebind resources to TransactionSynchronizationManager if managing any.

See Also:
  - `TransactionSynchronizationManager.bindResource(java.lang.Object, java.lang.Object)`

### flush

default void flush()
Flush the underlying session to the datastore, if applicable: for example, a Hibernate/JPA session.

Specified by:
  `flush` in interface `Flushable`
See Also:
  - `TransactionStatus.flush()`

### savepoint

default void savepoint(Object savepoint)
Invoked on creation of a new savepoint, either when a nested transaction is started against an existing transaction or on a programmatic savepoint via `TransactionStatus`.

This synchronization callback is invoked right after the creation of the resource savepoint, with the given savepoint object already active.

Parameters:
  `savepoint` - the associated savepoint object (primarily as a key for identifying the savepoint but also castable to the resource savepoint type)
Since:
  6.2
See Also:
  - `SavepointManager.createSavepoint()`
  - `TransactionDefinition.PROPAGATION_NESTED`

### savepointRollback

default void savepointRollback(Object savepoint)
Invoked in case of a rollback to the previously created savepoint.

This synchronization callback is invoked right before the rollback of the resource savepoint, with the given savepoint object still active.

Parameters:
  `savepoint` - the associated savepoint object (primarily as a key for identifying the savepoint but also castable to the resource savepoint type)
Since:
  6.2
See Also:
  - `savepoint(java.lang.Object)`
  - `SavepointManager.rollbackToSavepoint(java.lang.Object)`

### beforeCommit

default void beforeCommit(boolean readOnly)
Invoked before transaction commit (before "beforeCompletion"). Can, for example, flush transactional O/R Mapping sessions to the database.

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.

Parameters:
  `readOnly` - whether the transaction is defined as read-only transaction
Throws:
  `RuntimeException` - in case of errors; will be propagated to the caller (note: do not throw TransactionException subclasses here!)
See Also:
  - `beforeCompletion()`

### beforeCompletion

default void beforeCompletion()
Invoked before transaction commit/rollback. Can perform resource cleanup before transaction completion.

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.

Throws:
  `RuntimeException` - in case of errors; will be logged but not propagated (note: do not throw TransactionException subclasses here!)
See Also:
  - `beforeCommit(boolean)`
  - `afterCompletion(int)`

### afterCommit

default void afterCommit()
Invoked after transaction commit. Can perform further operations right after the main transaction has successfully committed.

Can, for example, 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.

Throws:
  `RuntimeException` - in case of errors; will be propagated to the caller (note: do not throw TransactionException subclasses here!)

### afterCompletion

default void afterCompletion(int status)
Invoked after transaction commit/rollback. Can perform resource cleanup after transaction completion.

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.

Parameters:
  `status` - completion status according to the `STATUS_*` constants
Throws:
  `RuntimeException` - in case of errors; will be logged but not propagated (note: do not throw TransactionException subclasses here!)
See Also:
  - `STATUS_COMMITTED`
  - `STATUS_ROLLED_BACK`
  - `STATUS_UNKNOWN`
  - `beforeCompletion()`