diff --git a/framework-docs/modules/ROOT/pages/data-access/transaction/declarative/annotations.adoc b/framework-docs/modules/ROOT/pages/data-access/transaction/declarative/annotations.adoc
index c8a83923b5..a866ccb564 100644
--- a/framework-docs/modules/ROOT/pages/data-access/transaction/declarative/annotations.adoc
+++ b/framework-docs/modules/ROOT/pages/data-access/transaction/declarative/annotations.adoc
@@ -74,10 +74,11 @@ Kotlin::
 ----
 ======
 
-Used at the class level as above, the annotation indicates a default for all methods of
-the declaring class (as well as its subclasses). Alternatively, each method can be
-annotated individually. See xref:data-access/transaction/declarative/annotations.adoc#transaction-declarative-annotations-method-visibility[method visibility] for
-further details on which methods Spring considers transactional. Note that a class-level
+Used at the class level as above, the annotation indicates a default for all methods
+of the declaring class (as well as its subclasses). Alternatively, each method can be
+annotated individually. See
+xref:data-access/transaction/declarative/annotations.adoc#transaction-declarative-annotations-method-visibility[method visibility]
+for further details on which methods Spring considers transactional. Note that a class-level
 annotation does not apply to ancestor classes up the class hierarchy; in such a scenario,
 inherited methods need to be locally redeclared in order to participate in a
 subclass-level annotation.
@@ -436,9 +437,10 @@ properties of the `@Transactional` annotation:
 | Optional array of exception name patterns that must not cause rollback.
 |===
 
-TIP: See xref:data-access/transaction/declarative/rolling-back.adoc#transaction-declarative-rollback-rules[Rollback rules] for further details
-on rollback rule semantics, patterns, and warnings regarding possible unintentional
-matches for pattern-based rollback rules.
+TIP: See
+xref:data-access/transaction/declarative/rolling-back.adoc#transaction-declarative-rollback-rules[Rollback rules]
+for further details on rollback rule semantics, patterns, and warnings
+regarding possible unintentional matches for pattern-based rollback rules.
 
 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.
diff --git a/framework-docs/modules/ROOT/pages/data-access/transaction/declarative/rolling-back.adoc b/framework-docs/modules/ROOT/pages/data-access/transaction/declarative/rolling-back.adoc
index 1de4c5af25..166fb73243 100644
--- a/framework-docs/modules/ROOT/pages/data-access/transaction/declarative/rolling-back.adoc
+++ b/framework-docs/modules/ROOT/pages/data-access/transaction/declarative/rolling-back.adoc
@@ -24,8 +24,8 @@ Vavr's `Try` method to trigger transaction rollbacks when it returns a 'Failure'
 This allows you to handle functional-style errors using Try and have the transaction
 automatically rolled back in case of a failure. For more information on Vavr's Try,
 refer to the https://docs.vavr.io/#_try[official Vavr documentation].
-
 Here's an example of how to use Vavr's Try with a transactional method:
+
 [tabs]
 ======
 Java::
@@ -42,6 +42,32 @@ Java::
 ----
 ======
 
+As of Spring Framework 6.1, there is also special treatment of `CompletableFuture`
+(and general `Future`) return values, triggering a rollback for such a handle if it
+was exceptionally completed at the time of being returned from the original method.
+This is intended for `@Async` methods where the actual method implementation may
+need to comply with a `CompletableFuture` signature (auto-adapted to an actual
+asynchronous handle for a call to the proxy by `@Async` processing at runtime),
+preferring exposure in the returned handle rather than rethrowing an exception:
+
+[tabs]
+======
+Java::
++
+[source,java,indent=0,subs="verbatim,quotes",role="primary"]
+----
+	@Transactional @Async
+	public CompletableFuture<String> myTransactionalMethod() {
+		try {
+			return CompletableFuture.completedFuture(delegate.myDataAccessOperation());
+		}
+		catch (DataAccessException ex) {
+			return CompletableFuture.failedFuture(ex);
+		}
+	}
+----
+======
+
 Checked exceptions that are thrown from a transactional method do not result in a rollback
 in the default configuration. You can configure exactly which `Exception` types mark a
 transaction for rollback, including checked exceptions by specifying _rollback rules_.