apache / apache/incubator-seata
Refactor SpringFenceHandler to Improve Code Structure and Reduce Complexity
- Dominant language
- Java
- Stars
- 26k
- Forks
- 8.8k
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 4
Description
### Check Ahead
- [x] I have searched the [issues](https://github.com/seata/seata/issues) of this repository and believe that this is not a duplicate.
- [x] I am willing to try to implement this feature myself.
### Why you need it?
I've been seata TCC model to research on, when I saw the org. Apache. Seata. Rm. Fence. SpringFenceHandler this code when I found the following questions, I wonder whether if necessary I can try to refactor the code
1. The class is a bit large and the logic is too complex. handler should serve as a processing entry point instead of integrating all the logic within it.
2. Database operations, transaction processing, and asynchronous cleaning are all piled up together. It will be very painful to make changes later
我最近在研究seata的TCC模式的实现,当我看到org.apache.seata.rm.fence.SpringFenceHandler这块代码的时候我发现有以下几个问题,我在想如果有必要的话我是否可以尝试重构这块的代码
1、类稍微有点大,逻辑太杂,handler应该作为一个处理入口,而不是柔和所有的逻辑在里面,
2、数据库操作、事务处理、异步清理这些东西全堆一块了,后面改起来会很痛苦
### How it could be?
_No response_
### Other related information
_No response_
Contributor guide
Research direction
Start by reading org.apache.seata.rm.fence.SpringFenceHandler and tracing its database operations, transaction processing, and asynchronous cleanup responsibilities. Define a refactoring plan that preserves the handler's behavior while separating those concerns; done means the resulting structure is simpler and the existing behavior remains intact.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend, distributed-systems
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100