Annotation Interface Transactional
When this annotation is declared at the class level, it applies as a default to all methods of the declaring class and its subclasses. Note that it does not apply to ancestor classes up the class hierarchy; inherited methods need to be locally redeclared in order to participate in a subclass-level annotation. For details on method visibility constraints, consult the Transaction Management section of the reference manual.
This annotation is generally directly comparable to Spring's
RuleBasedTransactionAttribute
class, and in fact AnnotationTransactionAttributeSource
will directly
convert this annotation's attributes to properties in RuleBasedTransactionAttribute
,
so that Spring's transaction support code does not have to know about annotations.
Attribute Semantics
If no custom rollback rules are configured in this annotation, the transaction
will roll back on RuntimeException
and Error
but not on checked
exceptions.
Rollback rules determine if a transaction should be rolled back when a given
exception is thrown, and the rules are based on types or patterns. Custom
rules may be configured via rollbackFor()
/noRollbackFor()
and
rollbackForClassName()
/noRollbackForClassName()
, which allow
rules to be specified as types or patterns, respectively.
When a rollback rule is defined with an exception type, that type will be
used to match against the type of a thrown exception and its super types,
providing type safety and avoiding any unintentional matches that may occur
when using a pattern. For example, a value of
jakarta.servlet.ServletException.class
will only match thrown exceptions
of type jakarta.servlet.ServletException
and its subclasses.
When a rollback rule is defined with an exception pattern, the pattern can
be a fully qualified class name or a substring of a fully qualified class name
for an exception type (which must be a subclass of Throwable
), with no
wildcard support at present. For example, a value of
"jakarta.servlet.ServletException"
or "ServletException"
will
match jakarta.servlet.ServletException
and its subclasses.
WARNING: You must carefully consider how specific a pattern
is and whether to include package information (which isn't mandatory). For example,
"Exception"
will match nearly anything and will probably hide other
rules. "java.lang.Exception"
would be correct if "Exception"
were meant to define a rule for all checked exceptions. With more unique
exception names such as "BaseBusinessException"
there is likely no
need to use the fully qualified class name for the exception pattern. Furthermore,
rollback rules defined via patterns may result in unintentional matches for
similarly named exceptions and nested classes. This is due to the fact that a
thrown exception is considered to be a match for a given pattern-based rollback
rule if the name of thrown exception contains the exception pattern configured
for the rollback rule. For example, given a rule configured to match against
"com.example.CustomException"
, that rule will match against an exception
named com.example.CustomExceptionV2
(an exception in the same package as
CustomException
but with an additional suffix) or an exception named
com.example.CustomException$AnotherException
(an exception declared as
a nested class in CustomException
).
For specific information about the semantics of other attributes in this
annotation, consult the TransactionDefinition
and TransactionAttribute
javadocs.
Transaction Management
This annotation commonly works with thread-bound transactions managed by a
PlatformTransactionManager
, exposing a
transaction to all data access operations within the current execution thread.
Note: This does NOT propagate to newly started threads within the method.
Alternatively, this annotation may demarcate a reactive transaction managed
by a ReactiveTransactionManager
which
uses the Reactor context instead of thread-local variables. As a consequence,
all participating data access operations need to execute within the same
Reactor context in the same reactive pipeline.
Note: When configured with a ReactiveTransactionManager
, all
transaction-demarcated methods are expected to return a reactive pipeline.
Void methods or regular return types need to be associated with a regular
PlatformTransactionManager
, e.g. through transactionManager()
.
- Since:
- 1.2
- Author:
- Colin Sampaleanu, Juergen Hoeller, Sam Brannen, Mark Paluch
- See Also:
-
Optional Element Summary
Modifier and TypeOptional ElementDescriptionThe transaction isolation level.String[]
Defines zero (0) or more transaction labels.String[]
Defines zero (0) or more exception name patterns (for exceptions which must be a subclass ofThrowable
) indicating which exception types must not cause a transaction rollback.The transaction propagation type.boolean
A boolean flag that can be set totrue
if the transaction is effectively read-only, allowing for corresponding optimizations at runtime.String[]
Defines zero (0) or more exception name patterns (for exceptions which must be a subclass ofThrowable
), indicating which exception types must cause a transaction rollback.int
The timeout for this transaction (in seconds).The timeout for this transaction (in seconds).A qualifier value for the specified transaction.Alias fortransactionManager()
.
-
Element Details
-
value
Alias fortransactionManager()
.- See Also:
- Default:
- ""
-
transactionManager
A qualifier value for the specified transaction.May be used to determine the target transaction manager, matching the qualifier value (or the bean name) of a specific
TransactionManager
bean definition.- Since:
- 4.2
- See Also:
- Default:
- ""
-
label
String[] labelDefines zero (0) or more transaction labels.Labels may be used to describe a transaction, and they can be evaluated by individual transaction managers. Labels may serve a solely descriptive purpose or map to pre-defined transaction manager-specific options.
See the documentation of the actual transaction manager implementation for details on how it evaluates transaction labels.
- Since:
- 5.3
- See Also:
- Default:
- {}
-
propagation
Propagation propagationThe transaction propagation type.Defaults to
Propagation.REQUIRED
.- Default:
- REQUIRED
-
isolation
Isolation isolationThe transaction isolation level.Defaults to
Isolation.DEFAULT
.Exclusively designed for use with
Propagation.REQUIRED
orPropagation.REQUIRES_NEW
since it only applies to newly started transactions. Consider switching the "validateExistingTransactions" flag to "true" on your transaction manager if you'd like isolation level declarations to get rejected when participating in an existing transaction with a different isolation level.- See Also:
- Default:
- DEFAULT
-
timeout
int timeoutThe timeout for this transaction (in seconds).Defaults to the default timeout of the underlying transaction system.
Exclusively designed for use with
Propagation.REQUIRED
orPropagation.REQUIRES_NEW
since it only applies to newly started transactions.- Returns:
- the timeout in seconds
- See Also:
- Default:
- -1
-
timeoutString
String timeoutStringThe timeout for this transaction (in seconds).Defaults to the default timeout of the underlying transaction system.
Exclusively designed for use with
Propagation.REQUIRED
orPropagation.REQUIRES_NEW
since it only applies to newly started transactions.- Returns:
- the timeout in seconds as a String value, e.g. a placeholder
- Since:
- 5.3
- See Also:
- Default:
- ""
-
readOnly
boolean readOnlyA boolean flag that can be set totrue
if the transaction is effectively read-only, allowing for corresponding optimizations at runtime.Defaults to
false
.This just serves as a hint for the actual transaction subsystem; it will not necessarily cause failure of write access attempts. A transaction manager which cannot interpret the read-only hint will not throw an exception when asked for a read-only transaction but rather silently ignore the hint.
- See Also:
- Default:
- false
-
rollbackFor
Defines zero (0) or more exception types, which must be subclasses ofThrowable
, indicating which exception types must cause a transaction rollback.By default, a transaction will be rolled back on
RuntimeException
andError
but not on checked exceptions (business exceptions). SeeDefaultTransactionAttribute.rollbackOn(Throwable)
for a detailed explanation.This is the preferred way to construct a rollback rule (in contrast to
rollbackForClassName()
), matching the exception type and its subclasses in a type-safe manner. See the class-level javadocs for further details on rollback rule semantics.- See Also:
- Default:
- {}
-
rollbackForClassName
String[] rollbackForClassNameDefines zero (0) or more exception name patterns (for exceptions which must be a subclass ofThrowable
), indicating which exception types must cause a transaction rollback.See the class-level javadocs for further details on rollback rule semantics, patterns, and warnings regarding possible unintentional matches.
- See Also:
- Default:
- {}
-
noRollbackFor
Defines zero (0) or more exceptiontypes
, which must be subclasses ofThrowable
, indicating which exception types must not cause a transaction rollback.This is the preferred way to construct a rollback rule (in contrast to
noRollbackForClassName()
), matching the exception type and its subclasses in a type-safe manner. See the class-level javadocs for further details on rollback rule semantics.- See Also:
- Default:
- {}
-
noRollbackForClassName
String[] noRollbackForClassNameDefines zero (0) or more exception name patterns (for exceptions which must be a subclass ofThrowable
) indicating which exception types must not cause a transaction rollback.See the class-level javadocs for further details on rollback rule semantics, patterns, and warnings regarding possible unintentional matches.
- See Also:
- Default:
- {}
-