Skip to content
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

Add aggressive-locking mechanism and support locking with conflict #528

Merged
merged 41 commits into from
Dec 1, 2022

Conversation

MyonKeminta
Copy link
Contributor

Requires: tikv/tikv#12749

This PR adapts to the new behavior of acquire_pessimistic_lock requests in the PR above.
This PR is experimental and still under development.

@MyonKeminta MyonKeminta force-pushed the m/pessimistic-lock-optimization branch from f11b130 to 552885c Compare June 20, 2022 08:26
Signed-off-by: MyonKeminta <[email protected]>
@MyonKeminta MyonKeminta force-pushed the m/pessimistic-lock-optimization branch 9 times, most recently from 7241c1c to 7736f37 Compare June 24, 2022 07:56
Signed-off-by: MyonKeminta <[email protected]>
@MyonKeminta MyonKeminta force-pushed the m/pessimistic-lock-optimization branch from 7736f37 to 1078efa Compare June 24, 2022 08:17
@MyonKeminta MyonKeminta changed the title [DNM] Support not-atomic pessimistic lock request and lock with conflict Add aggressive-locking mechanism and support locking with conflict Nov 23, 2022
@MyonKeminta
Copy link
Contributor Author

/race-test

@MyonKeminta
Copy link
Contributor Author

/run-race-test

Signed-off-by: MyonKeminta <[email protected]>
Signed-off-by: MyonKeminta <[email protected]>
Signed-off-by: MyonKeminta <[email protected]>
@MyonKeminta
Copy link
Contributor Author

MyonKeminta commented Nov 24, 2022

The tests look not sufficient to me now, but this PR is large enough. Considering that this PR is not expected to affect the original logic, I think I can add more tests in further PRs.

Signed-off-by: MyonKeminta <[email protected]>
Comment on lines 228 to 253
if err != nil {
return true, err
}
if regionErr != nil {
// For other region error and the fake region error, backoff because
// there's something wrong.
// For the real EpochNotMatch error, don't backoff.
if regionErr.GetEpochNotMatch() == nil || locate.IsFakeRegionError(regionErr) {
err = bo.Backoff(retry.BoRegionMiss, errors.New(regionErr.String()))
if err != nil {
return true, err
}
}
same, err := batch.relocate(bo, c.store.GetRegionCache())
if err != nil {
return true, err
}
if same {
return false, nil
}
err = c.pessimisticLockMutations(bo, action.LockCtx, action.wakeUpMode, batch.mutations)
return true, err
}
if resp.Resp == nil {
return true, errors.WithStack(tikverr.ErrBodyMissing)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There seem to be some duplicates with the implementation in handlePessimisticLockResponseForceMode, could it be abstracted to a single function?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. Btw I just realize that some of the code to handle the partially-successful cases is not removed. I'll remove them.

Comment on lines 294 to 311
var locks []*txnlock.Lock
for _, keyErr := range keyErrs {
// Check already exists error
if alreadyExist := keyErr.GetAlreadyExist(); alreadyExist != nil {
e := &tikverr.ErrKeyExist{AlreadyExist: alreadyExist}
return true, c.extractKeyExistsErr(e)
}
if deadlock := keyErr.Deadlock; deadlock != nil {
return true, errors.WithStack(&tikverr.ErrDeadlock{Deadlock: deadlock})
}

// Extract lock from key error
lock, err1 := txnlock.ExtractLockFromKeyErr(keyErr)
if err1 != nil {
return true, err1
}
locks = append(locks, lock)
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There seem to be some duplicates with the implementation in handlePessimisticLockResponseForceMode, could it be abstracted to a single function?

@@ -594,6 +650,185 @@ func (txn *KVTxn) LockKeysWithWaitTime(ctx context.Context, lockWaitTime int64,
return txn.LockKeys(ctx, lockCtx, keysInput...)
}

// StartAggressiveLocking makes the transaction enters aggressive locking state.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The aggressive locked keys processing functions are complex, we may need more SQL tests to verify it's working as expected.


if retryMutations != nil && retryMutations.Len() < batch.mutations.Len() {
// The request may be partially succeeded. Replace the request with remaining mutations.
// The primary lock (if it's in this request) must have been succeeded.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is it ensured? (Though it's not important when we only enable this mode for single key)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TiKV should ensure it. But since this kind of code is useless in current version, I'm now removing them.

Copy link
Contributor

@cfzjywxk cfzjywxk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rest LGTM

Signed-off-by: MyonKeminta <[email protected]>
@cfzjywxk
Copy link
Contributor

cfzjywxk commented Dec 1, 2022

@sticnarf PTAL
I think there is still quite some work to do in the tidb execution path.

@disksing disksing merged commit 5dc09b1 into tikv:master Dec 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants