Currently we always lock the prc exection first, as a pattern to avoid dead lock.
E.g. processing a timer task could potentially involving localQueue updates which stored in prc execution.
However, in some (or maybe many) cases, an state execution will only have timer, without any localQueue. This means locking/selecting the prc execution will be wasteful.
A probly better idea:
Select state execution without lock (no for update), which won't aquire lock for the state exec
if proc execution is needed update(need update localQ), then select prc execution for update
Then update state execution using version to ensure there is no racing condition with other (because we didn't use select for update for the state exec)
So the better patten is, within a transaction:
select without lock for state execution first
if need to get prc exectuion, then select for update prc execution before updating state execution -- this will ensure aquiring lock of proc execution before the lock of state exec
update state execution using version to avoid racing condition
Currently we always lock the prc exection first, as a pattern to avoid dead lock.
E.g. processing a timer task could potentially involving localQueue updates which stored in prc execution. However, in some (or maybe many) cases, an state execution will only have timer, without any localQueue. This means locking/selecting the prc execution will be wasteful.
A probly better idea:
So the better patten is, within a transaction: