root
/
spring-framework
mirror of https://github.com/spring-projects/spring-framework.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Polishing

This commit is contained in:
Sam Brannen 2024-03-06 15:42:14 +01:00
parent b32a2cadfb
commit 40da093f58
1 changed files with 10 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
framework-docs/modules/ROOT/pages/data-access/transaction/declarative/annotations.adoc
View File

@ -442,7 +442,7 @@ regarding possible unintentional matches for pattern-based rollback rules.
[NOTE] [NOTE]
==== ====
As of 6.2, you can globally change the default rollback behavior: e.g. through As of 6.2, you can globally change the default rollback behavior – for example, through
`@EnableTransactionManagement(rollbackOn=ALL_EXCEPTIONS)`, leading to a rollback `@EnableTransactionManagement(rollbackOn=ALL_EXCEPTIONS)`, leading to a rollback
for all exceptions raised within a transaction, including any checked exception. for all exceptions raised within a transaction, including any checked exception.
For further customizations, `AnnotationTransactionAttributeSource` provides an For further customizations, `AnnotationTransactionAttributeSource` provides an
@ -450,21 +450,22 @@ For further customizations, `AnnotationTransactionAttributeSource` provides an
Note that transaction-specific rollback rules override the default behavior but Note that transaction-specific rollback rules override the default behavior but
retain the chosen default for unspecified exceptions. This is the case for retain the chosen default for unspecified exceptions. This is the case for
Spring's `@Transactional` as well as JTA's `jakarta.transaction.Transactional`. Spring's `@Transactional` as well as JTA's `jakarta.transaction.Transactional`
annotation.
Unless you rely on EJB-style business exceptions with commit behavior, it is Unless you rely on EJB-style business exceptions with commit behavior, it is
advisable to switch to `ALL_EXCEPTIONS` for a consistent rollback even in case advisable to switch to `ALL_EXCEPTIONS` for consistent rollback semantics even
of a (potentially accidental) checked exception. Also, it is advisable to make in case of a (potentially accidental) checked exception. Also, it is advisable
that switch for Kotlin-based applications where there is no enforcement of to make that switch for Kotlin-based applications where there is no enforcement
checked exceptions at all. of checked exceptions at all.
==== ====
Currently, you cannot have explicit control over the name of a transaction, where 'name' Currently, you cannot have explicit control over the name of a transaction, where 'name'
means the transaction name that appears in a transaction monitor and in logging output. means the transaction name that appears in a transaction monitor and in logging output.
For declarative transactions, the transaction name is always the fully-qualified class For declarative transactions, the transaction name is always the fully-qualified class
name + `.` + the method name of the transactionally advised class. For example, if the name of the transactionally advised class + `.` + the method name. For example, if the
`handlePayment(..)` method of the `BusinessService` class started a transaction, the `handlePayment(..)` method of the `BusinessService` class started a transaction, the
name of the transaction would be: `com.example.BusinessService.handlePayment`. name of the transaction would be `com.example.BusinessService.handlePayment`.
[[tx-multiple-tx-mgrs-with-attransactional]] [[tx-multiple-tx-mgrs-with-attransactional]]
== Multiple Transaction Managers with `@Transactional` == Multiple Transaction Managers with `@Transactional`
@ -565,7 +566,7 @@ e.g. with a value of "order" it can be used for autowiring purposes (identifying
the order repository) as well as transaction manager selection, as long as the the order repository) as well as transaction manager selection, as long as the
target beans for autowiring as well as the associated transaction manager target beans for autowiring as well as the associated transaction manager
definitions declare the same qualifier value. Such a qualifier value only needs definitions declare the same qualifier value. Such a qualifier value only needs
to be unique with a set of type-matching beans, not having to serve as an id. to be unique within a set of type-matching beans, not having to serve as an ID.
==== ====
[[tx-custom-attributes]] [[tx-custom-attributes]]