PessimisticLock: Lock the specified key only if the key exists

[TonsnakeLin]

1. current process
Currently, TiKV locks the specified keys for pessimistic lock requests whether it exists or not. TiDB sends a get request to judge whether the keys exists on the TiKV firstly, then sends a pessimistic lock request to TiKV if the key exists, It makes and additional rpc request.

2. what changed
We add a flag LockIfExists for pessimistic lock request and TiKV will check the flag to decide how to execute the lock process.

This PR is depended on the PRs bellow.

• proto: add lock_if_fields in PessimisticLockRequest pingcap/kvproto#963
• PessmistincLock: Lock the key if it exists tikv#13210

[MyonKeminta]

Maybe there's better to be some unit tests, which requires the lock_if_exist logic to be implemented in mocktikv

[sticnarf]

LGTM

[sticnarf]

I'm considering this case, if a transaction called lock-if-exist requests in its first statement and all the given keys do not exist, but the lock keys requests are successful, then we set the primary key to an unlocked key, I'm afraid there will be some problems when this happened. See the following timeline:

begin
lock([k1, k2, k3]), TiKV resp with []
set PK as k1

Besides this case, if k1 doesn't exist, but we succeed locking k2 and k3, we'll face the same problem.

If we don't want to introduce an anchor key, we can disable the feature if the primary key is not selected yet.

[TonsnakeLin]

I'm considering this case, if a transaction called lock-if-exist requests in its first statement and all the given keys do not exist, but the lock keys requests are successful, then we set the primary key to an unlocked key, I'm afraid there will be some problems when this happened. See the following timeline:

begin
lock([k1, k2, k3]), TiKV resp with []
set PK as k1

LockOnlyIfExists request is used only for RC isolation on TiDB, I think the scene above is reasonable,right ?
Of course, I don't limit it in client-go.

[TonsnakeLin]

I'm considering this case, if a transaction called lock-if-exist requests in its first statement and all the given keys do not exist, but the lock keys requests are successful, then we set the primary key to an unlocked key, I'm afraid there will be some problems when this happened. See the following timeline:

begin
lock([k1, k2, k3]), TiKV resp with []
set PK as k1

Besides this case, if k1 doesn't exist, but we succeed locking k2 and k3, we'll face the same problem.

If we don't want to introduce an anchor key, we can disable the feature if the primary key is not selected yet.

[TonsnakeLin]

I'm considering this case, if a transaction called lock-if-exist requests in its first statement and all the given keys do not exist, but the lock keys requests are successful, then we set the primary key to an unlocked key, I'm afraid there will be some problems when this happened. See the following timeline:

begin
lock([k1, k2, k3]), TiKV resp with []
set PK as k1

Besides this case, if k1 doesn't exist, but we succeed locking k2 and k3, we'll face the same problem.

If we don't want to introduce an anchor key, we can disable the feature if the primary key is not selected yet.

If lock failed with LockIfExists flag, I will unset the primary key and reset ttlManager

[TonsnakeLin]

@sticnarf @MyonKeminta PTAL, thank you!!

[MyonKeminta]

If lock failed with LockIfExists flag, I will unset the primary key and reset ttlManager

It seems you meant when the pessimistic lock request succeeded but the primary lock is not acquired due to not exist, instead of failing to execute the pessimistic lock request.

Though you unset the primary and cancel ttlManager in the client side (which I think you can actually avoid starting the ttlManager instead of start it and then stop it), there still exists another problem.

Consider the case that a lock request to [k1, k2, k3] where k1 is the primary, and k2, k3 is locked but k1 is untouched due to not exist. In this case, k2 and k3 will still be locked with their primary pointing to k1. This causes other transactions cannot determine the transaction's state correctly through the lock on k2 and k3, which I'm afraid may potentially lead to other correctness issues.

cc @sticnarf @you06 @cfzjywxk

[TonsnakeLin]

If lock failed with LockIfExists flag, I will unset the primary key and reset ttlManager

It seems you meant when the pessimistic lock request succeeded but the primary lock is not acquired due to not exist, instead of failing to execute the pessimistic lock request.

Though you unset the primary and cancel ttlManager in the client side (which I think you can actually avoid starting the ttlManager instead of start it and then stop it), there still exists another problem.

Consider the case that a lock request to [k1, k2, k3] where k1 is the primary, and k2, k3 is locked but k1 is untouched due to not exist. In this case, k2 and k3 will still be locked with their primary pointing to k1. This causes other transactions cannot determine the transaction's state correctly through the lock on k2 and k3, which I'm afraid may potentially lead to other correctness issues.

cc @sticnarf @you06 @cfzjywxk

Thanks! As @sticnarf said, I will make the LockIfExists effective only when primary key is selected

[sticnarf]

Consider the case that a lock request to [k1, k2, k3] where k1 is the primary, and k2, k3 is locked but k1 is untouched due to not exist. In this case, k2 and k3 will still be locked with their primary pointing to k1. This causes other transactions cannot determine the transaction's state correctly through the lock on k2 and k3, which I'm afraid may potentially lead to other correctness issues.

If the use case is limited to single key point get, the current solution may suffice, because no other key may refer to a non-existing primary lock.

So, another solution is to check whether only one key is passed to LockKeys.

[MyonKeminta]

Rest LGTM

[cfzjywxk]

Need to check len(keysInput) > 0 first?

[TonsnakeLin]

if len(keysInput) == 0, it prints "{}".

[cfzjywxk]

if len(keysInput) == 0, would keysInput[0] cause index out of range?

[TonsnakeLin]

done