GitHub user funky-eyes added a comment to the discussion: Proposal for global_table Cleanup Optimization in Seata Transacion Coordinator
I don't believe that leveraging other components to solve this issue is a reasonable solution. Here's why: 1. ShardingSphere itself relies on Seata to handle distributed transaction problems. When data is sharded, distributed transaction issues inherently arise, which would create a circular dependency. 2. Sharding doesn't resolve the problem where the rate of new transaction creation significantly outpaces the rate of transaction deletion. This is because transactions in 'rollbacking' and 'committing' states are processed serially by a single thread, which makes the deletion rate very slow. 3. We shouldn't introduce an even more complex component to solve an already complex problem, as this could lead to further complications. Additionally, users unfamiliar with ShardingSphere would need to learn about this new component, increasing their learning curve and the overall cost of adoption. 4. The global table name is configurable. If each TC (Transaction Coordinator) node uses a different global table name, that inherently provides sharding capability. A complex solution like the one proposed is entirely unnecessary to address this problem. GitHub link: https://github.com/apache/incubator-seata/discussions/7362#discussioncomment-13267055 ---- This is an automatically sent email for dev@seata.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@seata.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@seata.apache.org For additional commands, e-mail: dev-h...@seata.apache.org
