# Overview An "optimistic" concurrency control strategy is... #flashcard A non-locking concurrency control that assumes multiple transaction can occur without interfering with each other. It is used in systems with low data contention (i.e., high reads, but low writes). As part of the strategy, locks are not acquired at the start of [[Database Transactions]]. Instead, conflicts are checked at commit time. If there is a conflict, a resolution is applied, such as a rollback or retry. <!--ID: 1751507776452--> Conflicts can be checked by maintaining a version number for the row, or by checking fields that may have changed during the processing. # Key Considerations Examples include: - [[Serializable Snapshot Isolation (SSI)]] - The [[ABA Problem]] ## Pros of optimistic locking strategies #flashcard - Prevents locking of resources to allow for uninterrupted processing, thus improving performance - Works well when the system can handle retry logic smoothly <!--ID: 1751507776455--> ## Cons of optimistic locking strategies #flashcard - If too many transactions prove to have contention, then performance will be hurt by the restarting of said transactions <!--ID: 1751507776458--> # Use Cases - Applications with limited contention # Related Topics