terrymanu commented on issue #37092:
URL:
https://github.com/apache/shardingsphere/issues/37092#issuecomment-3531285969
Problem Understanding
Thank you for raising this important architectural question. I understand
you wish ShardingSphere could directly use Seata's @GlobalTransaction
annotation instead of the current @Transactional annotation.
Core Architectural Design Explanation
After deep analysis, I need to clarify a crucial fact: ShardingSphere is
not a wrapper for Seata, but a technology-neutral middleware that supports
multiple transaction managers.
ShardingSphere's Transaction Architecture
// ShardingSphere's pluggable transaction manager architecture
ShardingSphereDistributedTransactionManager (SPI interface)
├── SeataATShardingSphereTransactionManager (Seata AT mode)
├── XAShardingSphereTransactionManager (XA mode - Atomikos)
└── NarayanaShardingSphereTransactionManager (XA mode - Narayana)
Key Facts:
- Seata is just one of many providers, not the main flow
- ShardingSphere must maintain a technology-neutral architectural design
- Unified API is a necessary choice to maintain architectural consistency
Why We Cannot Use Specific Provider APIs in the Main Flow
1. Architectural Consistency Principle
If we support Seata's @GlobalTransaction, then:
- Should we also support Atomikos' native annotations?
- Should we also support Narayana's native APIs?
- Each provider has its own API, and the main flow would become chaotic
2. Technology Neutrality Requirement
// ✅ ShardingSphere design: technology-neutral
@Transactional
public void businessMethod() {
// Underlying can be Seata, XA, or LOCAL - users don't need to care
}
// ❌ If we support specific APIs: technology binding
@GlobalTransaction // This would tightly couple ShardingSphere with Seata
public void businessMethod() {
// Users cannot switch to other transaction managers
}
3. Pluggability is Core Value
# Users can easily switch between different transaction managers
transaction:
defaultType: BASE # Seata mode
providerType: Seata
# Or switch to XA mode
transaction:
defaultType: XA # XA mode
providerType: Atomikos # Or Narayana
If the main flow is bound to Seata APIs, this flexible switching becomes
impossible.
Official Documentation Usage Guidelines
Based on this architectural design, the official documentation clearly
explains 7 usage scenarios:
Allowed (technology-neutral):
- @Transactional (Spring Framework)
- javax.transaction.Transactional (Jakarta EE 8)
- jakarta.transaction.Transactional (Jakarta EE 9/10)
Not Allowed (technology-specific):
- @GlobalTransactional (Seata native API)
Recommended Correct Usage
Configuration File
transaction:
defaultType: BASE
providerType: Seata
Java Code
import org.springframework.transaction.annotation.Transactional;
@Service
public class BusinessService {
@Transactional
public void performBusinessOperation() {
// Your business logic
// ShardingSphere will automatically use Seata for distributed
transactions
}
}
Conclusion
This is not a design flaw, but an architectural advantage:
- ShardingSphere provides a unified transaction API supporting multiple
transaction managers
- Seata is just one of many pluggable providers
- Technology-neutral architecture ensures future extensibility and user
freedom of choice
I recommend trying ShardingSphere's recommended approach of @Transactional
+ BASE configuration. This way, you can get complete distributed transaction
capabilities while maintaining architectural consistency and
maintainability.
If you have specific business requirements that cannot be met through
current approaches, please describe them in detail, and we can explore more
appropriate solutions.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
