Pending async commit transactions don't necessarily block read about sig-transaction HOT 4 OPEN

cc @nrc @youjiali1995 @MyonKeminta @cfzjywxk

from sig-transaction.

We could do some benchmarks for the read-write conflict scenarios with different data distributions to show the impact. Currently I agree it's not urgent and we need to make the basic async-commit stable before introducing new improvements.

from sig-transaction.

Did you mean that the transaction's lock can be skipped if we did CheckSecondaryLocks on one if its keys that's not yet locked?
Sounds correct, but I'm afraid that if you do the CheckTxnStatus - CheckSecondaryLocks procedure even when the lock's TTL is not expired, it may cause too many these requests when there are many transaction conflicts and maybe results in lower performance.

from sig-transaction.

Did you mean that the transaction's lock can be skipped if we did CheckSecondaryLocks on one if its keys that's not yet locked?
Sounds correct, but I'm afraid that if you do the CheckTxnStatus - CheckSecondaryLocks procedure even when the lock's TTL is not expired, it may cause too many these requests when there are many transaction conflicts and maybe results in lower performance.

Yes. And it's why I suggest this only happens after several times of backoffs.

from sig-transaction.