optimize: Replace @LocalTCC with @SagaTransactional in the saga annotation pattern #7443
Conversation
…endency-7439' into fix-saga-annotation-localtcc-dependency-7439 # Conflicts: # integration-tx-api/src/test/java/org/apache/seata/integration/tx/api/remoting/parser/TransactionParticipantIntegrationTest.java # tcc/src/main/java/org/apache/seata/rm/tcc/remoting/parser/LocalTCCRemotingParser.java # tcc/src/test/java/org/apache/seata/rm/tcc/remoting/parser/LocalTCCRemotingParserTest.java # test/src/test/java/org/apache/seata/saga/annotation/AnnotationConflictTest.java
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## 2.x #7443 +/- ##
============================================
- Coverage 61.20% 61.04% -0.17%
- Complexity 652 666 +14
============================================
Files 1310 1316 +6
Lines 49587 49800 +213
Branches 5837 5855 +18
============================================
+ Hits 30349 30398 +49
- Misses 16526 16694 +168
+ Partials 2712 2708 -4
... and 13 files with indirect coverage changes 🚀 New features to boost your workflow:
|
compatible/src/main/java/io/seata/rm/tcc/remoting/parser/LocalTCCRemotingParser.java
Show resolved
Hide resolved
| @Retention(RetentionPolicy.RUNTIME) | ||
| @Target(ElementType.TYPE) | ||
| @Inherited | ||
| public @interface TransactionParticipant { |
There was a problem hiding this comment.
Firstly, it is only applied in the TCC and SAGA annotation modes. Secondly, this naming is rather ambiguous and doesn't clearly relate to its functionality.
There was a problem hiding this comment.
@funky-eyes, thanks for your review! I'd like to address your concerns:
Regarding " it is only applied in the TCC and SAGA annotation modes":
The annotation aims to solve this limitation by being more generic. Here are the location options:
Option A: Current location common/transaction/api
- ✅ Generic design - not limited to specific transaction modes
- ✅ Future extensibility for other transaction patterns
- ✅ Resolves the scope limitation you mentioned
Option B: More focused location integration-tx-api/annotation
- ✅ Co-located with other transaction annotations like
AspectTransactional - ✅ More focused on annotation-based transaction integration
- ✅ Still maintains proper module dependencies
Regarding the naming:
How about LocalTransactionResource provides clearer semantics than TransactionParticipant:
- "Local" - clearly indicates it's for local (non-remote) resources
- "TransactionResource" - directly relates to its functionality
- Avoids the ambiguity you pointed out
Which approach do you prefer? Or do you have other suggestions for the design?
There was a problem hiding this comment.
@funky-eyes, thanks for your review! I'd like to address your concerns:
Regarding " it is only applied in the TCC and SAGA annotation modes":
The annotation aims to solve this limitation by being more generic. Here are the location options:
Option A: Current location
common/transaction/api
- ✅ Generic design - not limited to specific transaction modes
- ✅ Future extensibility for other transaction patterns
- ✅ Resolves the scope limitation you mentioned
Option B: More focused location
integration-tx-api/annotation
- ✅ Co-located with other transaction annotations like
AspectTransactional- ✅ More focused on annotation-based transaction integration
- ✅ Still maintains proper module dependencies
Regarding the naming: How about
LocalTransactionResourceprovides clearer semantics thanTransactionParticipant:
- "Local" - clearly indicates it's for local (non-remote) resources
- "TransactionResource" - directly relates to its functionality
- Avoids the ambiguity you pointed out
Which approach do you prefer? Or do you have other suggestions for the design?
Regarding the naming, I lean towards TransactionParticipant instead of LocalTransactionResource. We could enhance TransactionParticipant with a parameter for the transaction mode. This would also allow it to handle more common settings in the future, like AT mode's isolation level. Consequently, configuring the lock retry interval via @GlobalTransaction would become unnecessary, since @GlobalTransaction is primarily for TM, not for RM. This new annotation could also enable local transaction features, like connection reuse until the aspect finishes and a unified commit. Or could it be changed to LocalTransactional? Or SeataLocalTransactional?
@slievrly @xingfudeshi @YongGoose @xjlgod PTAL
There was a problem hiding this comment.
If it can also enable local transaction features like a unified commit, I'd cast my vote for LocalTransactional.
There was a problem hiding this comment.
@funky-eyes @YongGoose Thanks for the feedback! I've adopted the @LocalTransactional naming as suggested by @YongGoose.
Regarding transaction mode parameters:
@funky-eyes Your suggestion about enhancing with transaction mode parameters and AT isolation levels is excellent for future iterations. For this PR, I focused on the core issue #7439 - removing Saga's semantic dependency on @LocalTCC. The current simple annotation provides a clean foundation that can be enhanced later.
This keeps the current PR focused while leaving room for those valuable enhancements in follow-up work.
There was a problem hiding this comment.
@funky-eyes @YongGoose Thanks for the feedback! I've adopted the
@LocalTransactionalnaming as suggested by @YongGoose.Regarding transaction mode parameters: @funky-eyes Your suggestion about enhancing with transaction mode parameters and AT isolation levels is excellent for future iterations. For this PR, I focused on the core issue #7439 - removing Saga's semantic dependency on
@LocalTCC. The current simple annotation provides a clean foundation that can be enhanced later. This keeps the current PR focused while leaving room for those valuable enhancements in follow-up work.
I agree with your opinion. However, the name of this annotation may need to be approved by the majority of the community at the next weekly meeting before this PR can be merged.
There was a problem hiding this comment.
The community's final decision is to separate the Saga annotation mode into a distinct annotation similar to LocalTCC, which will be dedicated exclusively to the Saga annotation mode.
There was a problem hiding this comment.
Thank you for the clarification!
I understand the community's decision to create a dedicated annotation for Saga mode. I can easily adapt my current @LocalTransactional implementation to create a Saga-specific annotation.
What do you think about @SagaTransactional as the naming?
compatible/src/main/java/io/seata/rm/tcc/remoting/parser/LocalTCCRemotingParser.java
Outdated
Show resolved
Hide resolved
- Add new @LocalTransactional annotation to replace @TransactionParticipant - Update all test files to use new annotation names - Fix comments and documentation to reflect naming changes - Maintain backward compatibility with @LocalTCC
- Add new @LocalTransactional annotation in common module for general transaction participation - Update LocalTCCRemotingParser to support both @LocalTCC and @LocalTransactional annotations - Maintain backward compatibility with existing @LocalTCC usage - Optimize method naming and code structure for better maintainability - Simplify JavaDoc comments using plain text format - Fix annotation detection priority: interface annotations take precedence over implementation class annotations Resolves apache#7439: Remove the dependency of Saga annotations on @LocalTCC
…endency-7439' into fix-saga-annotation-localtcc-dependency-7439
# Conflicts: # tcc/src/test/java/org/apache/seata/rm/tcc/remoting/parser/LocalTCCRemotingParserTest.java
|
Hi all,@funky-eyes @YongGoose @pengten.
Does this approach look good to the community? I'll proceed with implementation once confirmed. |
Sounds good to me. |
- Add @SagaTransactional annotation in saga-annotation module - Implement SagaTransactionalRemotingParser for Saga-specific handling - Register SagaTransactionalRemotingParser via SPI - Remove dependency on @LocalTCC for Saga scenarios - Add comprehensive test coverage for new annotation - Maintain backward compatibility with existing @LocalTCC usage
I agree |
tcc/src/test/java/org/apache/seata/rm/tcc/remoting/parser/LocalTCCRemotingParserTest.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Pull Request Overview
This PR introduces a dedicated @SagaTransactional annotation to decouple Saga transaction mode from the TCC-specific @LocalTCC annotation, addressing semantic confusion in Saga scenarios while maintaining full backward compatibility.
- Creates a new
@SagaTransactionalannotation specifically designed for Saga transaction participants - Implements
SagaTransactionalRemotingParserto handle the new annotation independently from TCC - Adds comprehensive SPI integration for automatic parser discovery and registration
Reviewed Changes
Copilot reviewed 15 out of 15 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| SagaTransactional.java | New annotation with comprehensive documentation for Saga scenarios |
| SagaTransactionalRemotingParser.java | Dedicated parser handling @SagaTransactional annotations with optimized logic |
| META-INF/services/RemotingParser | SPI registration enabling automatic discovery |
| LocalTCC.java | Enhanced documentation clarifying usage patterns and relationship with Saga |
| Test files | Comprehensive test coverage for new functionality and dual parser integration |
Comments suppressed due to low confidence (1)
tcc/src/main/java/org/apache/seata/rm/tcc/api/LocalTCC.java:1
- The guidance 'Generic transaction participants (non-TCC specific)' under @SagaTransactional usage is confusing since @SagaTransactional is specifically for Saga scenarios, not for generic cases. Consider clarifying this point or removing it to avoid confusion.
/*
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
...main/resources/META-INF/services/org.apache.seata.integration.tx.api.remoting.RemotingParser
Outdated
Show resolved
Hide resolved
tcc/src/main/java/org/apache/seata/rm/tcc/api/TwoPhaseBusinessAction.java
Outdated
Show resolved
Hide resolved
…Action.java Co-authored-by: Copilot <[email protected]>
…s/org.apache.seata.integration.tx.api.remoting.RemotingParser Co-authored-by: Copilot <[email protected]>
funky-eyes
left a comment
There was a problem hiding this comment.
Please register your PR in those two files :
https://github.com/apache/incubator-seata/blob/2.x/changes/zh-cn/2.x.md
https://github.com/apache/incubator-seata/blob/2.x/changes/en-us/2.x.md
Done in 10acfb5. |
Co-authored-by: funkye <[email protected]>
Co-authored-by: funkye <[email protected]>
Ⅰ. Describe what this PR did
This PR implements a dedicated
@SagaTransactionalannotation to decouple Saga transaction mode from the TCC-specific@LocalTCCannotation, addressing the semantic confusion in Saga scenarios.Key Changes:
New
@SagaTransactionalAnnotationsaga-annotationmodule for semantic clarityDedicated
SagaTransactionalRemotingParser@SagaTransactionalannotationsSPI Integration
META-INF/services/org.apache.seata.integration.tx.api.remoting.RemotingParserEnhanced Documentation
Backward Compatibility
@LocalTCCfunctionality remains unchangedⅡ. Does this pull request fix one issue?
Closes #7439
Ⅲ. Why don't you add test cases (unit test/integration test)?
Ⅳ. Describe how to verify it
./mvnw test -Dtest=SagaTransactionalTest,SagaTransactionalRemotingParserTest -pl saga/seata-saga-annotation@LocalTCCservices continue to work unchanged@SagaTransactionalfor better semantic clarityⅤ. Special notes for reviews
Backward Compatibility:
Code Quality:
Documentation: