codingapi / codingapi/tx-lcn

事务超时,发起方服务没有清理事务(clean transaction)的过程

Open
#280 2 comments 0 reactions 0 assignees View on GitHub
v/preBug
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的过程。

如下是参与方设置断点导致整体事务超时的事务过程:
![image](https://user-images.githubusercontent.com/7507599/53802418-bebc0b00-3f7c-11e9-9d3d-871316a025ac.png)

如下是发起方设置断点导致整体事务超时的事务过程:
![image](https://user-images.githubusercontent.com/7507599/53802758-9bde2680-3f7d-11e9-9caf-df232c19133a.png)

### 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.