public abstract class TransactionSynchronizationAdapter extends Object implements TransactionSynchronization, Ordered
TransactionSynchronization
adapter containing empty
method implementations, for easier overriding of single methods.
Also 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.
STATUS_COMMITTED, STATUS_ROLLED_BACK, STATUS_UNKNOWN
HIGHEST_PRECEDENCE, LOWEST_PRECEDENCE
Constructor and Description |
---|
TransactionSynchronizationAdapter() |
Modifier and Type | Method and Description |
---|---|
void |
afterCommit()
Invoked after transaction commit.
|
void |
afterCompletion(int status)
Invoked after transaction commit/rollback.
|
void |
beforeCommit(boolean readOnly)
Invoked before transaction commit (before "beforeCompletion").
|
void |
beforeCompletion()
Invoked before transaction commit/rollback.
|
void |
flush()
Flush the underlying session to the datastore, if applicable:
for example, a Hibernate/JPA session.
|
int |
getOrder()
Return the order value of this object, with a
higher value meaning greater in terms of sorting.
|
void |
resume()
Resume this synchronization.
|
void |
suspend()
Suspend this synchronization.
|
public int getOrder()
Ordered
Normally starting with 0, with Integer.MAX_VALUE
indicating the greatest value. Same order values will result
in arbitrary positions for the affected objects.
Higher values can be interpreted as lower priority. As a consequence, the object with the lowest value has highest priority (somewhat analogous to Servlet "load-on-startup" values).
public void suspend()
TransactionSynchronization
suspend
in interface TransactionSynchronization
TransactionSynchronizationManager.unbindResource(java.lang.Object)
public void resume()
TransactionSynchronization
resume
in interface TransactionSynchronization
TransactionSynchronizationManager.bindResource(java.lang.Object, java.lang.Object)
public void flush()
TransactionSynchronization
flush
in interface TransactionSynchronization
TransactionStatus.flush()
public void beforeCommit(boolean readOnly)
TransactionSynchronization
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.
beforeCommit
in interface TransactionSynchronization
readOnly
- whether the transaction is defined as read-only transactionTransactionSynchronization.beforeCompletion()
public void beforeCompletion()
TransactionSynchronization
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.
beforeCompletion
in interface TransactionSynchronization
TransactionSynchronization.beforeCommit(boolean)
,
TransactionSynchronization.afterCompletion(int)
public void afterCommit()
TransactionSynchronization
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.
afterCommit
in interface TransactionSynchronization
public void afterCompletion(int status)
TransactionSynchronization
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.
afterCompletion
in interface TransactionSynchronization
status
- completion status according to the STATUS_*
constantsTransactionSynchronization.STATUS_COMMITTED
,
TransactionSynchronization.STATUS_ROLLED_BACK
,
TransactionSynchronization.STATUS_UNKNOWN
,
TransactionSynchronization.beforeCompletion()