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

tikv: check lock timeout again after resolving lock #14066

Merged
merged 5 commits into from
Dec 16, 2019

Conversation

sticnarf
Copy link
Contributor

Signed-off-by: Yilin Chen [email protected]

What problem does this PR solve?

Fix #14063

What is changed and how it works?

Before resolving locks, we checked whether the locks are expired according to its own TTL. However, it's not accurate because heartbeat only updates the TTL of the primary key.

So we still fetch msBeforeTxnExpired from ResolveLocks. If msBeforeTxnExpired is not zero, it means there are still locks blocking us acquiring the pessimistic lock. We should return timeout error if necessary.

Check List

Tests

  • Unit test

Code changes

  • Has exported function/method change

Side effects

Related changes

  • Need to cherry-pick to the release branch

Release note

  • Write release note for bug-fix or new feature.

@codecov
Copy link

codecov bot commented Dec 16, 2019

Codecov Report

Merging #14066 into master will decrease coverage by 0.4903%.
The diff coverage is 75%.

@@               Coverage Diff                @@
##             master     #14066        +/-   ##
================================================
- Coverage   80.6472%   80.1568%   -0.4904%     
================================================
  Files           488        483         -5     
  Lines        124659     121150      -3509     
================================================
- Hits         100534      97110      -3424     
+ Misses        16373      16296        -77     
+ Partials       7752       7744         -8

@@ -750,33 +750,49 @@ func (action actionPessimisticLock) handleSingleBatch(c *twoPhaseCommitter, bo *
// if the lock left behind whose related txn is already committed or rollbacked,
// (eg secondary locks not committed or rollbacked yet)
// we cant return "nowait conflict" directly
if lock.LockType == pb.Op_PessimisticLock {
Copy link
Member

Choose a reason for hiding this comment

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

Why remove this check?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think the check is necessary. Blocking by an optimistic lock is possible with large transaction. (Or am I forgetting something...?)

Signed-off-by: Yilin Chen <[email protected]>
// Heartbeats will increase the TTL of the primary key

// wait until secondary key exceeds its own TTL
time.Sleep(time.Duration(ManagedLockTTL) * time.Millisecond)
Copy link
Contributor

Choose a reason for hiding this comment

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

Sleep 20s in the test?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In tests it's 3 seconds. I guess it's acceptable?

store/tikv/2pc_test.go Outdated Show resolved Hide resolved
Signed-off-by: Yilin Chen <[email protected]>
@tiancaiamao
Copy link
Contributor

LGTM

@tiancaiamao tiancaiamao added the status/LGT1 Indicates that a PR has LGTM 1. label Dec 16, 2019
@coocood
Copy link
Member

coocood commented Dec 16, 2019

@sticnarf
Can we only check timeout after resolve the locks?

@sticnarf
Copy link
Contributor Author

I've removed the check before resolve lock. PTAL @coocood @tiancaiamao

@coocood
Copy link
Member

coocood commented Dec 16, 2019

LGTM

@coocood coocood added status/LGT2 Indicates that a PR has LGTM 2. and removed status/LGT1 Indicates that a PR has LGTM 1. labels Dec 16, 2019
Copy link
Contributor

@youjiali1995 youjiali1995 left a comment

Choose a reason for hiding this comment

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

LGTM

@coocood
Copy link
Member

coocood commented Dec 16, 2019

/merge

@sre-bot sre-bot added the status/can-merge Indicates a PR has been approved by a committer. label Dec 16, 2019
@coocood coocood added status/LGT3 The PR has already had 3 LGTM. and removed status/LGT2 Indicates that a PR has LGTM 2. labels Dec 16, 2019
@sre-bot
Copy link
Contributor

sre-bot commented Dec 16, 2019

/run-all-tests

@sre-bot sre-bot merged commit 814015e into pingcap:master Dec 16, 2019
@sre-bot
Copy link
Contributor

sre-bot commented Dec 16, 2019

cherry pick to release-3.0 failed

sticnarf added a commit to sticnarf/tidb that referenced this pull request Dec 16, 2019
Reminiscent pushed a commit to Reminiscent/tidb that referenced this pull request Dec 17, 2019
XiaTianliang pushed a commit to XiaTianliang/tidb that referenced this pull request Dec 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/tikv status/can-merge Indicates a PR has been approved by a committer. status/LGT3 The PR has already had 3 LGTM. type/bugfix This PR fixes a bug.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

dead loop in acquire pessimistic lock when secondary keys exceed TTL
5 participants