public class SpringSessionSynchronization extends Object implements TransactionSynchronization, Ordered
STATUS_COMMITTED, STATUS_ROLLED_BACK, STATUS_UNKNOWNHIGHEST_PRECEDENCE, LOWEST_PRECEDENCE| Constructor and Description |
|---|
SpringSessionSynchronization(SessionHolder sessionHolder,
SessionFactory sessionFactory) |
SpringSessionSynchronization(SessionHolder sessionHolder,
SessionFactory sessionFactory,
boolean newSession) |
| 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()
Get the order value of this object.
|
void |
resume()
Resume this synchronization.
|
void |
suspend()
Suspend this synchronization.
|
public SpringSessionSynchronization(SessionHolder sessionHolder, SessionFactory sessionFactory)
public SpringSessionSynchronization(SessionHolder sessionHolder, SessionFactory sessionFactory, boolean newSession)
public int getOrder()
OrderedHigher values are interpreted as lower priority. As a consequence,
the object with the lowest value has the highest priority (somewhat
analogous to Servlet load-on-startup values).
Same order values will result in arbitrary sort positions for the affected objects.
getOrder in interface OrderedOrdered.HIGHEST_PRECEDENCE,
Ordered.LOWEST_PRECEDENCEpublic void suspend()
TransactionSynchronizationsuspend in interface TransactionSynchronizationTransactionSynchronizationManager.unbindResource(java.lang.Object)public void resume()
TransactionSynchronizationresume in interface TransactionSynchronizationTransactionSynchronizationManager.bindResource(java.lang.Object, java.lang.Object)public void flush()
TransactionSynchronizationflush in interface Flushableflush in interface TransactionSynchronizationTransactionStatus.flush()public void beforeCommit(boolean readOnly)
throws DataAccessException
TransactionSynchronizationThis 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 TransactionSynchronizationreadOnly - whether the transaction is defined as read-only transactionDataAccessExceptionTransactionSynchronization.beforeCompletion()public void beforeCompletion()
TransactionSynchronizationThis 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 TransactionSynchronizationTransactionSynchronization.beforeCommit(boolean),
TransactionSynchronization.afterCompletion(int)public void afterCommit()
TransactionSynchronizationCan 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 TransactionSynchronizationpublic void afterCompletion(int status)
TransactionSynchronizationNOTE: 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 TransactionSynchronizationstatus - completion status according to the STATUS_* constantsTransactionSynchronization.STATUS_COMMITTED,
TransactionSynchronization.STATUS_ROLLED_BACK,
TransactionSynchronization.STATUS_UNKNOWN,
TransactionSynchronization.beforeCompletion()