txn: Unexpected transaction behavior when tidb connection got killed.

[longfangsong]

Bug Report

1. Minimal reproduce step & What did you expect to see? & What did you see instead?

# mysql client 1
begin;
update cjl.test set name='111' where id=1;

# mysql client 2
begin;
update cjl.test set name='222' where id=1;
# blocked

# mysql client 3
kill tidb <connection id of mysql client 1>;

# mysql client 1
begin;
# > ERROR 2013 (HY000): Lost connection to MySQL server during query
begin;
# > No connection. Trying to reconnect...
# > Connection id:    XXX
# > Current database: *** NONE ***
update cjl.test set name='111' where id=1;

Then either mysql client 1 or mysql client 2 should be blocked, but occationally, neither of them did.

And in that situation, if you try to commit both of them, txn in mysql client 1 will commit successfully, txn in mysql client 2 will report PessimisticLockNotFound.

2. What is your TiDB version? (Required)

Found on all 4.0 and 5.0 versions.

Note: still exists when pessimistic-txn.pipelined='false';

[longfangsong]

/assign

[cfzjywxk]

If the pessimistic lock wait takes some long time greater than the ManagedLockTTL which is 20s, the ttlManager may not update the new ttl in time as it will update every ManagedLockTTL/2 time every round. The conflict transaction could resolve the lock before the first time ttl time update.

To reduce this possibility, the ttl field could be updated locking keys.