事务超时,发起方服务没有清理事务(clean transaction)的过程
- Dominant language
- Java
- Stars
- 4.2k
- Forks
- 1.4k
- PR merge metrics
- No merged PRs in 30d
Description
- I have searched the [issues](https://github.com/codingapi/tx-lcn/issues) of this repository and believe that this is not a duplicate.
### 1. Bug Description
(不知道是不是bug,先请谅解)
服务A、B,A发起事务调用B。
测试A服务和B服务超时后事务的控制过程(通过断点实现,模拟业务处理时间过长造成整体事务超时),发现发起方A服务的事务没有清理(clean transaction)的过程,导致A服务锁表。参与方B服务有clean transaction的过程。
如下是参与方设置断点导致整体事务超时的事务过程:

如下是发起方设置断点导致整体事务超时的事务过程:

### 2. Environment:
- JDK version: 1.8
- OS: win7
- TX-LCN version: 5.0.1
- Others: Oracle 数据库
### 3. Exception Stacktrace
```
Paste your Exception Stacktrace here!
```
### 4. Tour Idea
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reproducing the timeout flow between services A and B using the described breakpoint-based delay, then compare the initiator and participant transaction cleanup sequences shown in the screenshots. Trace why the initiator retains its transaction and locks the table; done means the initiator performs cleanup after the overall transaction times out, without leaving the lock behind.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- databases, distributed-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100