Package io.micronaut.transaction.support

Interface TransactionSynchronization

All Superinterfaces:
io.micronaut.core.order.Ordered
public interface TransactionSynchronization extends io.micronaut.core.order.Ordered
Interface for transaction synchronization callbacks.

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.

Since:
02.06.2003
Author:
Juergen Hoeller
See Also:

  • Nested Class Summary

    Nested Classes
    Modifier and Type
    Interface
    Description
    static enum 
    TransactionSynchronization.Status
    Transaction synchronization status.

  • Field Summary

    Fields inherited from interface io.micronaut.core.order.Ordered

    HIGHEST_PRECEDENCE, LOWEST_PRECEDENCE

  • Method Summary

    Modifier and Type
    Method
    Description
    default void
    afterCommit()
    Invoked after transaction commit.
    default void
    afterCompletion(@NonNull TransactionSynchronization.Status 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.

    Methods inherited from interface io.micronaut.core.order.Ordered

    getOrder

  • Method Details

    • beforeCommit

      default void beforeCommit(boolean readOnly)
      Invoked before transaction commit (before "beforeCompletion"). Can e.g. 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

      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:

    • afterCommit

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

      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.

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

    • afterCompletion

      default void afterCompletion(@NonNull @NonNull TransactionSynchronization.Status 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: