Details
-
Sub-task
-
Resolution: Done
-
L3 - Default
-
None
-
None
Description
- Pessimistic locks as we use them do not help us due to serializable isolation level => after the pessimistic lock unblocks, the tx still sees old data; it only fails when it tries to do a conflicting modification
- Idea: we disable pessimistic locks for CRDB. This will lead to more failures in the corresponding commands (e.g. parallel deployment during server startup) => it should be possible to configure the retry interceptor for these cases
Pessimistic locks are used in the following scenario:
- create history cleanup jobs
- deployment
- telemetry
- installation id
- message correlation
We can support retries in the following scenarios:
- create history cleanup jobs
- deployment
- telemetry
- installation id
Retries for exclusive message correlation are useless, because the purpose of the feature is that the business logic during message correlation is guaranteed to run only once.
We should write appropriate test cases and once more confirm that without the pessimistic locks, nothing bad happens.