feature: implement early rollback of global transactions when TM disconnects

[kssumin]

• I have read the CONTRIBUTING.md guidelines.
• I have registered the PR changes in changes/en-us/2.x.md and changes/zh-cn/2.x.md.

Ⅰ. Describe what this PR did

This PR implements early rollback of global transactions when Transaction Manager (TM) disconnects, addressing issue #4422.

Key Features:

• Add TMDisconnectHandler interface for handling TM disconnect events
• Implement DefaultTMDisconnectHandler with VGroup-based matching logic
• Integrate TM disconnect detection in AbstractNettyRemotingServer
• Add configuration option server.enableRollbackWhenDisconnect (default: false)
• Performance improvement: reduces rollback delays from 60 seconds to <1 second

Implementation Details:

• Primary matching: TransactionServiceGroup (VGroup) - community consensus approach
• Secondary safety check: ApplicationId matching when available
• Status transition: BEGIN → TimeoutRollbacking → Rollback
• Configuration: server.enableRollbackWhenDisconnect=false (disabled by default for safety)

Ⅱ. Does this pull request fix one issue?

Yes, this PR fixes issue #4422: "rollback of global transactions ahead of time"

Problem: When TM crashes or disconnects, global transactions remain in BEGIN status for 60 seconds (default timeout), blocking resources and degrading system performance.

Solution: This feature enables immediate TM disconnect detection and early rollback processing, reducing resource lock time from 60 seconds to <1 second.

Ⅲ. Why don't you add test cases (unit test/integration test)?

I have added comprehensive test coverage:

Unit Tests:

• DefaultTMDisconnectHandlerTest: Tests core rollback logic and edge cases
• AbstractNettyRemotingServerTMDisconnectTest: Tests server-side integration

Integration Tests:

• TMDisconnectIntegrationTest: Tests end-to-end TM disconnect scenarios
• DefaultCoordinatorInitTest: Tests handler initialization and wiring

Test Coverage:

• Configuration enabled/disabled scenarios
• VGroup and ApplicationId matching logic
• Error handling and transaction state transitions
• Mock-based testing for cross-module dependencies

Ⅳ. Describe how to verify it

Testing:

# Run related tests
mvn test -Dtest="*TMDisconnect*,*DefaultCoordinator*" -pl server,core

# All tests pass with expected behavior:
# - TM disconnect detection works correctly
# - Rollback logic matches VGroup properly
# - Configuration controls feature activation
# - Error scenarios are handled gracefully

Manual Verification:

1. Enable feature: server.enableRollbackWhenDisconnect=true
2. Start transaction and simulate TM disconnect
3. Verify immediate rollback (logs show <1 second vs 60 second timeout)
4. Confirm resource locks are released quickly

Performance Test:

• Before: 60 seconds resource lock duration
• After: <1 second immediate rollback
• ~60x performance improvement in resource recovery

Ⅴ. Special notes for reviews

Safety Considerations:

• Feature is disabled by default (server.enableRollbackWhenDisconnect=false)
• Uses conservative VGroup + ApplicationId matching to prevent false positives
• Only affects transactions in BEGIN status
• Maintains backward compatibility

Key Code Areas:

• DefaultTMDisconnectHandler.shouldRollbackSession(): Core matching logic
• AbstractNettyRemotingServer.handleDisconnect(): TM disconnect detection
• Configuration integration for feature toggle

Performance Impact:

• No performance overhead when disabled (default)
• Minimal overhead when enabled (event-driven processing)
• Significant improvement in failure scenarios (60s → <1s)

Breaking Changes:

• None. Feature is disabled by default and fully backward compatible
• New configuration option: server.enableRollbackWhenDisconnect=false

Additional Notes:

• This addresses a long-standing performance issue in production environments
• VGroup-based matching follows community consensus approach from issue discussions
• Implementation is conservative to prevent false positive rollbacks

[Copilot]

Pull Request Overview

This PR implements early rollback of global transactions when Transaction Manager (TM) disconnects to improve system performance by reducing resource lock duration from 60 seconds to <1 second.

Key Changes:

• Added TM disconnect detection and handling infrastructure
• Implemented VGroup-based transaction matching for early rollback
• Added configuration toggle for the feature (disabled by default)

Reviewed Changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
TMDisconnectHandler.java	Interface for handling TM disconnect events
DefaultTMDisconnectHandler.java	Implementation with VGroup/ApplicationId matching logic
AbstractNettyRemotingServer.java	Integration of TM disconnect detection in server
DefaultCoordinator.java	Initialization of TM disconnect handler
ConfigurationKeys.java & DefaultValues.java	Configuration constants for feature toggle
Test files	Comprehensive unit and integration tests

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The error message format is unclear with three consecutive placeholders without descriptive text. Consider a more descriptive format like 'Failed to rollback transaction [{}]: code={}, message={}'

Suggested change

	"Failed to rollback transaction [{}] {} {}",
	"Failed to rollback transaction [{}]: code={}, message={}",

[Copilot]

This method is exposed solely for testing but exists in production code. Consider using package-private visibility instead of public, or use dependency injection to make the code more testable.

Suggested change

	public SessionManager getSessionManager() {
	SessionManager getSessionManager() {

[YongGoose]

@kssumin

Where did you handle the channelInactive event?

[kssumin]

@kssumin

Where did you handle the channelInactive event?

@YongGoose
The channelInactive() event handler already exists in AbstractNettyRemotingServer
(before this PR). I didn't modify it - instead, I integrated the TM disconnect logic into
the existing handleDisconnect() method that channelInactive() calls.

Event flow:
channelInactive() [existing code]
↓
handleDisconnect() [existing method, I added TM logic here]
↓if (TMROLE) → tmDisconnectHandler.handleTMDisconnect()

The commit diff doesn't show channelInactive() because I didn't change it.
The new logic is in handleDisconnect() at line 226-233.

Did I misunderstand your concern? If the explanation above isn't clear, I'm happy to add code comments or documentation to make the event flow more explicit.

[codecov]

Codecov Report

❌ Patch coverage is 84.48276% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 61.76%. Comparing base (d1ae495) to head (f772c72).
⚠️ Report is 23 commits behind head on 2.x.

Files with missing lines	Patch %	Lines
...ta/core/rpc/netty/AbstractNettyRemotingServer.java	28.57%	5 Missing ⚠️
...server/coordinator/DefaultTMDisconnectHandler.java	91.48%	3 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##                2.x    #7674      +/-   ##
============================================
+ Coverage     61.05%   61.76%   +0.70%     
- Complexity      670      684      +14     
============================================
  Files          1316     1325       +9     
  Lines         49804    50104     +300     
  Branches       5855     5917      +62     
============================================
+ Hits          30407    30945     +538     
+ Misses        16689    16373     -316     
- Partials       2708     2786      +78     

Files with missing lines	Coverage Δ
...ava/org/apache/seata/common/ConfigurationKeys.java	0.00% <ø> (ø)
...in/java/org/apache/seata/common/DefaultValues.java	100.00% <ø> (ø)
...e/seata/server/coordinator/DefaultCoordinator.java	49.64% <100.00%> (+0.48%)	⬆️
...server/coordinator/DefaultTMDisconnectHandler.java	91.48% <91.48%> (ø)
...ta/core/rpc/netty/AbstractNettyRemotingServer.java	14.63% <28.57%> (+0.84%)	⬆️

... and 85 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.