New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug about @GlobalLock in memory mode #1647
Comments
Bug about @GlobalLock in memory mode
Ⅰ. Issue DescriptionBug 1: When seata-server runs in memory mode, get global lock failure always happens(seata-server couldn't get the MemoryLocker because branchSession is null). When i resolve first bug, the second shows up. Bug 2: I change a sample project(springboot-dubbo-seata), and add a global lock test to it. This is only a little issue, campare with what i will talk about next. Bug 3: In description of Bug 2, we already know that global lock will check pks useability when do commit. Now consider follow situation:
In my opinion, once i use @GlobalLock and Ⅱ. Describe what happenedBUG1-TC:
BUG1-RM or BUG2-RM log:
Bug3 log, pay attention to
Ⅲ. Describe what you expected to happen@GlobalLock could work in memory mode Ⅳ. How to reproduce it (as minimally and precisely as possible)
Ⅴ. Anything else we need to know?Bug1 due to #942, i have no idea why exception message is In the previous version, check pks' lock to TC located in SelectForUpdateExecutor.
Ⅵ. Environment:
|
The message may be wrong,it should be "branchSession can't be null for memory/file"; |
@xingfudeshi |
Ⅰ. Issue Description
Bug 1: When seata-server runs in memory mode, get global lock failure always happens(seata-server couldn't get the MemoryLocker because branchSession is null).
When i resolve first bug, the second shows up.
Bug 2: I change a sample project(springboot-dubbo-seata), and add a global lock test to it.
When global transaction running, global lock feature will lost retry mechanism, because retry mechanism located in SelectForUpdateExecutor, but it only put the pks in context, and these pks's useability will been checked only if do commit, however at this time, retry process already finished.
This is only a little issue, campare with what i will talk about next.
Bug 3: In description of Bug 2, we already know that global lock will check pks useability when do commit. Now consider follow situation:
select for update
as a lock(with @GlobalLock)2.Another global transaction(GT) is runing too, and phase 1 just finished, but pks' lock is still holding by this global transaction in TC
select for update
in a local transaction(LT), with @GlobalLockIn my opinion, once i use @GlobalLock and
select for update
, my transaction is in READ_COMMITED level, but actually it isn't.Ⅱ. Describe what happened
BUG1-TC:
BUG1-RM or BUG2-RM log:
Bug3 log, pay attention to
Hi, i got lock, i will do some thing with holding this lock.
:Ⅲ. Describe what you expected to happen
@GlobalLock could work in memory mode
@GlobalLock could work with retry mechanism
@GlobalLock could make
select for update
execute in READ_COMMITED levelⅣ. How to reproduce it (as minimally and precisely as possible)
curl -H "Content-Type:application/json" -X GET localhost:8102/account/test_global_lock
io.seata.samples.integration.account.service.TAccountServiceImpl#testGlobalLock
and do step 4 again, you will find bug2Ⅴ. Anything else we need to know?
Bug1 due to #942, i have no idea why exception message is
branchSession can be null for memory/file locker.
, if branch session can be null, why throw a exception?In the previous version, check pks' lock to TC located in SelectForUpdateExecutor.
But it moved in #498, but this change seems like unnecesary:
Ⅵ. Environment:
The text was updated successfully, but these errors were encountered: