GH-36684: Document transaction coordination between DataSourceTransactionManager instances sharing a DataSource#36896
Open
won-seoop wants to merge 3 commits into
Conversation
…ux RequestContext.changeLocale() The Spring MVC RequestContext.changeLocale() delegates through the configured LocaleResolver and persists the locale across requests. The WebFlux equivalent only updates a field on the current RequestContext instance and the change is discarded at the end of the rendering cycle. This asymmetry was undocumented, leading developers to expect that calling changeLocale() in a WebFlux template would produce the same durable effect as in Spring MVC. Add Javadoc to both WebFlux overloads explaining that the change affects only the current rendering context, does not delegate to a LocaleContextResolver, and pointing developers towards the correct approach (WebFilter + LocaleContextResolver) for durable locale changes. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…nIdValid() to follow Servlet 6.1 spec Previously isRequestedSessionIdValid() always returned true by default, regardless of whether a session ID was actually supplied by the client or whether it still matched the current session. Per the Servlet 6.1 spec, isRequestedSessionIdValid() must return: - false when the client submitted no session ID - false when the submitted ID no longer matches the current session (e.g., after changeSessionId() is called) Change the backing field from boolean (default true) to @nullable Boolean (default null = calculate dynamically). When explicitly set via setRequestedSessionIdValid(), that value takes precedence, preserving full backwards-compatibility for tests that control the flag manually. When null, the method derives its answer from the current request state. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…nagers 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>
spring-projects-issues
added
the
status: waiting-for-triage
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Addresses #36684.
When two
DataSourceTransactionManagerbeans are configured with the sameDataSourceobject, the second manager'sgetTransaction()will detect and join the connection already bound to the thread by the first manager — because both use the sameTransactionSynchronizationManagerkey (theDataSourceinstance). The result is that both managers share the same JDBC connection and physical transaction.This behavior was not documented anywhere in the class-level Javadoc, causing confusion for developers trying to understand whether multiple managers operating on the same underlying resource can/will coordinate. The issue specifically asks for this to be documented.
This PR adds a Transaction manager coordination paragraph to
DataSourceTransactionManager's Javadoc explaining:DataSourceobject will participate in the same physical transaction.TransactionSynchronizationManagerkeyed byDataSourceinstance).DataSource(or JTA) if truly independent transactions are required.Test plan
🤖 Generated with Claude Code