apache / apache/incubator-seata
ConnectionProxy processLocalCommitWithGlobalLocks fail when commit secondly
- Dominant language
- Java
- Stars
- 26k
- Forks
- 8.8k
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 4
Description
- [ ] I have searched the [issues](https://github.com/seata/seata/issues) of this repository and believe that this is not a duplicate.
### Ⅰ. Issue Description
checkLock(context.buildLockKeys()); fail.
### Ⅱ. Describe what happened
AbstractDMLBaseExecutor.executeAutoCommitTrue will call connectionProxy.commit() and clear lockKey(context.reset()); finally connectionProxy.setAutoCommit(true) will be called.
However, change autocommit from false to true will call commit twice, lockKey is empty when checkLock.
`public void setAutoCommit(boolean autoCommit) throws SQLException {
if ((autoCommit) && !getAutoCommit()) {
// change autocommit from false to true, we should commit() first according to JDBC spec.
commit();
}
targetConnection.setAutoCommit(autoCommit);
}`
### Ⅲ. Describe what you expected to happen
### Ⅳ. How to reproduce it (as minimally and precisely as possible)
1. xxx
2. xxx
3. xxx
### Ⅴ. Anything else we need to know?
### Ⅵ. Environment:
- JDK version :
- OS :
- Others:
Contributor guide
Research direction
Start at AbstractDMLBaseExecutor.executeAutoCommitTrue and trace ConnectionProxy.commit(), setAutoCommit(), and the lockKey context through the failing checkLock(context.buildLockKeys()) call. Reproduce the duplicate-commit path described in the issue, then verify that committing with global locks no longer fails when the lock key has been cleared.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend, distributed-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100