Loosen pessimistic transactions: skip acquiring locks for some statements

[ekexium]

Enhancement

Pessimistic transactions acquire locks for all DMLs. We can selectively skip some locking for better performance, at the cost of a probably lower success rate. Namely support a transaction behavior somewhere between current optimistic and pessimistic transactions.

Example

Consider the workload: there is a table t on which you only do simple INSERT and SELECT. The INSERTs and SELECTs are performed in a transaction that will modify other tables where a pessimistic transaction is preferred. There may be multiple threads running the same workload.
You know you don't have to lock when inserting into t because if a conflicting concurrent insert happens, at most 1 transaction will succeed, while others will fail because of "duplicate key" errors. Skipping the lock of INSERT here and postponing the constraint check (namely the existence check) and conflict check to the prewrite phase can save you some requests for locking. The only downside is that a transaction won't know its INSERT failed until commit (previously it knows at the execution of the INSERT statement).

How

Pessimistic locks basically serve 2 purposes:

• Constraint check (existence check)
• Avoiding write conflict

Constraint check can be performed in prewrite as well. And we can perform a write conflict check just like in optimistic transactions for those keys that skipped acquiring pessimistic locks.

[tiancaiamao]

You mean skip the pessimistic lock for insert statement?
It doesn't affect the final correctness, but may break the "pessimistic" semantic.

For insert, we can try something like: optimistic first, and turn to pessimistic on conflict.
Oh, gosh... seems retry is removed

[ekexium]

Yes, it changes the semantics, so we leave the choice to users and do not change the default behavior.

[tiancaiamao]

Get it!