GH-36684: Document transaction coordination between managers sharing a DataSource

Two DataSourceTransactionManager instances configured with the same
DataSource object participate in the same JDBC connection and physical
transaction. This follows from both managers using the same
TransactionSynchronizationManager key (the DataSource instance), so the
second getTransaction() call detects and joins the existing connection.

This shared-DataSource behavior was previously undocumented, leading to
confusion about whether multiple transaction managers can truly coordinate.
Add a Javadoc paragraph to DataSourceTransactionManager explaining the
behavior and when to prefer separate DataSource instances or JTA.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: won-seoop

spring-jdbc/src/main/java/org/springframework/jdbc/datasource/DataSourceTransactionManager.java

@@ -106,6 +106,17 @@
  * is available as an extended subclass which includes commit/rollback exception
  * translation, aligned with {@link org.springframework.jdbc.core.JdbcTemplate}.</b>
  *
+ * <p><b>Transaction manager coordination:</b> When two {@code DataSourceTransactionManager}
+ * instances are configured with the <em>same</em> {@code DataSource} object, the second
+ * manager's {@code getTransaction()} will detect and participate in the connection already
+ * bound to the thread by the first, because both managers use the same
+ * {@link TransactionSynchronizationManager} key (the {@code DataSource} instance).
+ * As a result, nested {@code TransactionTemplate}/{@code @Transactional} calls that use
+ * different manager beans but the same underlying {@code DataSource} share the same JDBC
+ * connection and physical transaction. This is generally the desired behavior for such
+ * setups. If separate, independent transactions are required, configure each manager with
+ * a distinct {@code DataSource} (or use JTA).
+ *
  * @author Juergen Hoeller
  * @since 02.05.2003
  * @see #setNestedTransactionAllowed