Conversation
Signed-off-by: longfangsong <longfangsong@icloud.com>
78592fb to
64d6e44
Compare
Signed-off-by: longfangsong <longfangsong@icloud.com>
64d6e44 to
af5f586
Compare
Signed-off-by: longfangsong <longfangsong@icloud.com>
Signed-off-by: longfangsong <longfangsong@icloud.com>
c5a3056 to
b761265
Compare
txnkv/transaction/prewrite.go
Outdated
| } | ||
| start := time.Now() | ||
| msBeforeExpired, err := c.store.GetLockResolver().ResolveLocks(bo, c.startTS, locks) | ||
| defer c.store.GetLockResolver().ResolveLocksDone(c.startTS) |
There was a problem hiding this comment.
Why is the defer written in prewrite instead of in ResolveLocks? ResolveLocksDone looks missing if resolve lock is triggered by other commands.
There was a problem hiding this comment.
Why is the
deferwritten in prewrite instead of inResolveLocks?
It's because we need to keep the resolving infomation during backoffing. From the user's POV, we are doing the lock resolving work during backoffing.
ResolveLocksDone looks missing if resolve lock is triggered by other commands.
I've added them now.
Signed-off-by: longfangsong <longfangsong@icloud.com>
7d6ef2d to
49ca14d
Compare
txnkv/transaction/pessimistic.go
Outdated
| // tikv default will wait 3s(also the maximum wait value) when lock error occurs | ||
| startTime = time.Now() | ||
| msBeforeTxnExpired, err := c.store.GetLockResolver().ResolveLocks(bo, 0, locks) | ||
| defer c.store.GetLockResolver().ResolveLocksDone(c.startTS) |
There was a problem hiding this comment.
It's in a retry loop here. It seems we'd better protect it from being deferred more than once or do the call before entering the next loop? The same question to the prewrite part.
txnkv/txnlock/lock_resolver.go
Outdated
| return lr.resolveLocks(bo, callerStartTS, locks, true, lite) | ||
| } | ||
|
|
||
| func (lr *LockResolver) saveResolvingLocks(locks []*Lock, callerStartTS uint64) { |
There was a problem hiding this comment.
What if ResolveLocks happens concurrently for multiple regions?
For example, a batch get involves multiple regions and it encounters locks in more than one regions. But the resolving array always only includes the information of one region.
|
In this implementation, it requires all callers to |
Co-authored-by: MyonKeminta <9948422+MyonKeminta@users.noreply.github.com> Signed-off-by: longfangsong <longfangsong@icloud.com>
50c4871 to
4dc3ac0
Compare
|
Looks working but it seems to create more complexity to the code than I expected, though I don't have a good idea yet... |
Signed-off-by: longfangsong <longfangsong@icloud.com>
4dc3ac0 to
35484dd
Compare
No description provided.