txn: record resolving locks #473
Conversation
Signed-off-by: longfangsong <[email protected]>
longfangsong
force-pushed
the
lock_wait_resolving
branch
3 times, most recently
from
78592fb to
64d6e44
Compare
Signed-off-by: longfangsong <[email protected]>
longfangsong
force-pushed
the
lock_wait_resolving
branch
from
64d6e44 to
af5f586
Compare
Signed-off-by: longfangsong <[email protected]>
Signed-off-by: longfangsong <[email protected]>
longfangsong
force-pushed
the
lock_wait_resolving
branch
from
c5a3056 to
b761265
Compare
txnkv/transaction/prewrite.go
Outdated
| @@ -365,6 +365,7 @@ func (action actionPrewrite) handleSingleBatch(c *twoPhaseCommitter, bo *retry.B | |||
| } | |||
| 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 <[email protected]>
longfangsong
force-pushed
the
lock_wait_resolving
branch
from
7d6ef2d to
49ca14d
Compare
txnkv/transaction/pessimistic.go
Outdated
| @@ -227,6 +227,7 @@ func (action actionPessimisticLock) handleSingleBatch(c *twoPhaseCommitter, bo * | |||
| // 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 <[email protected]> Signed-off-by: longfangsong <[email protected]>
longfangsong
force-pushed
the
lock_wait_resolving
branch
2 times, most recently
from
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 <[email protected]>
longfangsong
force-pushed
the
lock_wait_resolving
branch
from
4dc3ac0 to
35484dd
Compare
No description provided.