Package io.micronaut.transaction.impl

Class TransactionManagerConfiguration

java.lang.Object
io.micronaut.transaction.impl.TransactionManagerConfiguration
public class TransactionManagerConfiguration extends Object
The transaction manager configuration.
Since:
4.0.0
Author:
Denis Stepanov

  • Constructor Details

    • TransactionManagerConfiguration

      public TransactionManagerConfiguration()

  • Method Details

    • setDefaultTimeout

      public final void setDefaultTimeout(Duration defaultTimeout)
      Specify the default timeout that this transaction manager should apply if there is no timeout specified at the transaction level, in seconds.

      Default is the underlying transaction infrastructure's default timeout, e.g. typically 30 seconds in case of a JTA provider, indicated by the TransactionDefinition.TIMEOUT_DEFAULT value.

      Parameters:
      defaultTimeout - The default timeout
      See Also:

    • getDefaultTimeout

      @NonNull public final @NonNull Optional<Duration> getDefaultTimeout()
      Return the default timeout that this transaction manager should apply if there is no timeout specified at the transaction level, in seconds.

      Returns TransactionDefinition.TIMEOUT_DEFAULT to indicate the underlying transaction infrastructure's default timeout.

      Returns:
      The default timeout

    • setNestedTransactionAllowed

      public final void setNestedTransactionAllowed(boolean nestedTransactionAllowed)
      Set whether nested transactions are allowed. Default is "false".

      Typically initialized with an appropriate default by the concrete transaction manager subclass.

      Parameters:
      nestedTransactionAllowed - Whether a nested transaction is allowed

    • isNestedTransactionAllowed

      public final boolean isNestedTransactionAllowed()
      Returns:
      Return whether nested transactions are allowed.

    • setValidateExistingTransaction

      public final void setValidateExistingTransaction(boolean validateExistingTransaction)
      Set whether existing transactions should be validated before participating in them.

      When participating in an existing transaction (e.g. with PROPAGATION_REQUIRED or PROPAGATION_SUPPORTS encountering an existing transaction), this outer transaction's characteristics will apply even to the inner transaction scope. Validation will detect incompatible isolation level and read-only settings on the inner transaction definition and reject participation accordingly through throwing a corresponding exception.

      Default is "false", leniently ignoring inner transaction settings, simply overriding them with the outer transaction's characteristics. Switch this flag to "true" in order to enforce strict validation.

      Parameters:
      validateExistingTransaction - Whether to validate an existing transaction
      Since:
      2.5.1

    • isValidateExistingTransaction

      public final boolean isValidateExistingTransaction()
      Return whether existing transactions should be validated before participating in them.
      Returns:
      Whether to validate existing transactions
      Since:
      2.5.1

    • setGlobalRollbackOnParticipationFailure

      public final void setGlobalRollbackOnParticipationFailure(boolean globalRollbackOnParticipationFailure)
      Set whether to globally mark an existing transaction as rollback-only after a participating transaction failed.

      Default is "true": If a participating transaction (e.g. with PROPAGATION_REQUIRED or PROPAGATION_SUPPORTS encountering an existing transaction) fails, the transaction will be globally marked as rollback-only. The only possible outcome of such a transaction is a rollback: The transaction originator cannot make the transaction commit anymore.

      Switch this to "false" to let the transaction originator make the rollback decision. If a participating transaction fails with an exception, the caller can still decide to continue with a different path within the transaction. However, note that this will only work as long as all participating resources are capable of continuing towards a transaction commit even after a data access failure: This is generally not the case for a Hibernate Session, for example; neither is it for a sequence of JDBC insert/update/delete operations.

      Note:This flag only applies to an explicit rollback attempt for a subtransaction, typically caused by an exception thrown by a data access operation (where TransactionInterceptor will trigger a PlatformTransactionManager.rollback() call according to a rollback rule). If the flag is off, the caller can handle the exception and decide on a rollback, independent of the rollback rules of the subtransaction. This flag does, however, not apply to explicit setRollbackOnly calls on a TransactionStatus, which will always cause an eventual global rollback (as it might not throw an exception after the rollback-only call).

      The recommended solution for handling failure of a subtransaction is a "nested transaction", where the global transaction can be rolled back to a savepoint taken at the beginning of the subtransaction. propagation NESTED provides exactly those semantics; however, it will only work when nested transaction support is available. This is the case with DataSourceTransactionManager, but not with JtaTransactionManager.

      Parameters:
      globalRollbackOnParticipationFailure - Whether to globally mark transaction as rollback only
      See Also:

    • isGlobalRollbackOnParticipationFailure

      public final boolean isGlobalRollbackOnParticipationFailure()
      Returns:
      Return whether to globally mark an existing transaction as rollback-only after a participating transaction failed.

    • setFailEarlyOnGlobalRollbackOnly

      public final void setFailEarlyOnGlobalRollbackOnly(boolean failEarlyOnGlobalRollbackOnly)
      Set whether to fail early in case of the transaction being globally marked as rollback-only.

      Default is "false", only causing an UnexpectedRollbackException at the outermost transaction boundary. Switch this flag on to cause an UnexpectedRollbackException as early as the global rollback-only marker has been first detected, even from within an inner transaction boundary.

      Parameters:
      failEarlyOnGlobalRollbackOnly - Sets whether to fail early on global rollback
      Since:
      2.0
      See Also:

    • isFailEarlyOnGlobalRollbackOnly

      public final boolean isFailEarlyOnGlobalRollbackOnly()
      Returns:
      Return whether to fail early in case of the transaction being globally marked as rollback-only.
      Since:
      2.0

    • setRollbackOnCommitFailure

      public final void setRollbackOnCommitFailure(boolean rollbackOnCommitFailure)
      Set whether doRollback should be performed on failure of the doCommit call. Typically not necessary and thus to be avoided, as it can potentially override the commit exception with a subsequent rollback exception.

      Default is "false".

      Parameters:
      rollbackOnCommitFailure - Sets whether to rollback on commit failure

    • isRollbackOnCommitFailure

      public final boolean isRollbackOnCommitFailure()
      Returns:
      Return whether doRollback should be performed on failure of the doCommit call.

    • determineTimeout

      public Optional<Duration> determineTimeout(TransactionDefinition definition)
      Determine the actual timeout to use for the given definition. Will fall back to this manager's default timeout if the transaction definition doesn't specify a non-default value.
      Parameters:
      definition - the transaction definition
      Returns:
      the actual timeout to use
      See Also:

    • setEnforceReadOnly

      public void setEnforceReadOnly(boolean enforceReadOnly)
      Specify whether to enforce the read-only nature of a transaction (as indicated by TransactionDefinition.isReadOnly() through an explicit statement on the transactional connection: "SET TRANSACTION READ ONLY" as understood by Oracle, MySQL and Postgres.

      This mode of read-only handling goes beyond the Connection.setReadOnly(boolean) hint that Spring applies by default. In contrast to that standard JDBC hint, "SET TRANSACTION READ ONLY" enforces an isolation-level-like connection mode where data manipulation statements are strictly disallowed. Also, on Oracle, this read-only mode provides read consistency for the entire transaction.

      Note that older Oracle JDBC drivers (9i, 10g) used to enforce this read-only mode even for Connection.setReadOnly(true. However, with recent drivers, this strong enforcement needs to be applied explicitly, e.g. through this flag.

      Parameters:
      enforceReadOnly - True if read-only should be enforced
      Since:
      4.3.7

    • isEnforceReadOnly

      public boolean isEnforceReadOnly()
      Returns:
      Return whether to enforce the read-only nature of a transaction through an explicit statement on the transactional connection.
      Since:
      4.3.7
      See Also: