seems better.

Can we seperate the pessimistic lock and shared lock handling into two different functions?

Maybe extract a function for these boilerplate code, eg.

fn must_decode_lock_into(either: &mut Either<Vec<u8>, Lock>) {
    if let Either::Left(encoded) = either {
        let lock = Lock::parse(encoded).expect("failed to parse shared lock txn info");
        *either = Either::Right(lock);
    }
}

Removed the must-decode implementation and return Result now.

It seems pingcap/kvproto#1377 is not supported in this PR?

So we will reject a shared lock req when there is an existing exclusive pessimistic lock even they come from the same txn (with same ts)? I see the previous impl allows this case.

Reject the exclusive lock downgrade is more strict. Since we haven't well design the desired behavior, I think it's ok to return error here.

The client of TiKV may not send shared lock request when adding shared lock above an exclusive lock (and prewrite with Op::Lock as well).

Yes, in this case, the kv client won't send a shared lock request when the key has already been locked.

Let txn1 aquire a shared lock on k first, then optimistic txn2 tries to prewrite k. Txn2 will fail with OtherError instead of KeyIsLocked ?

Nice catch, when an optimistic prewrite seeing a shared lock, it should return all the txn segments inside it.

Added a test that optimistic transaction will return KeyIsLocked error.

But it needs more changes to return multi locks for one mutation prewrite, I think we can do it in another PR.

OK