metric: the lock resolver counter for expired type is incorrect

[cfzjywxk]

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

Run some test having conflict read/write like ycsb tests.

2. What did you expect to see? (Required)

There should be few expired counter value.

3. What did you see instead (Required)

Many expired counter value.

4. What is your TiDB version? (Required)

The release-5.0-rc branch.

8df9dbb

The tikvLockResolverCountWithExpired collects value everytime for the transaction status with ttl == 0, but it does not mean the transaction is expired if the commitTS is greater than zero. The counter should increase only if the transaction is really expired.

[dwangxxx]

It means that we just need to update LockResolverCountWithExpired when the transaction is really expired (ttl==0 and commmitTS == 0)? If commitTS > 0, it means the transaction is committed, we should not update LockResolverCountWithExpired. Do I understand this correctly?

[cfzjywxk]

It means that we just need to update LockResolverCountWithExpired when the transaction is really expired (ttl==0 and commmitTS == 0)? If commitTS > 0, it means the transaction is committed, we should not update LockResolverCountWithExpired. Do I understand this correctly?

@dwangxxx
Yes currently the meaning of expire is confusing, we need to make it clear and document about it. Also we may need to check these metrics related to transactional status if they are correct.

[dwangxxx]

It means that we just need to update LockResolverCountWithExpired when the transaction is really expired (ttl==0 and commmitTS == 0)? If commitTS > 0, it means the transaction is committed, we should not update LockResolverCountWithExpired. Do I understand this correctly?

@dwangxxx Yes currently the meaning of expire is confusing, we need to make it clear and document about it. Also we may need to check these metrics related to transactional status if they are correct.

Ok, LockResolverCountWithExpired is implemented in client-go in master branch. Should I implement it in client-go or release-5.0-rc branch?