Optimistic locking
Optimistic locking detects on save whether a record has changed since the version that was read.
Compare the starting state when saving
Optimistic locking checks during a change whether the known record state still applies. A version identifier often provides the comparison value. In a fictional example, two people edit the same service address. After the first save, the second must not silently overwrite the changed state.
The version condition and write must be enforced reliably together. An earlier comparison followed by an unprotected write is insufficient. No long editing lock is held while a user enters data, although short locks may still occur during the database write. A detected conflict needs a business resolution, such as rereading and reviewing changes. The mechanism does not decide which input is correct.
Sources
Related terms
- Database lockA database lock coordinates concurrent access to data or database objects so incompatible operations do not proceed unchecked.
- Business ruleA business rule describes a business condition or decision that governs how an operation is handled.
- Legacy systemAn existing system still in use, with technical and business dependencies accumulated over time.
- Multi-tenancyMulti-tenancy supports separate customer or group scopes in one solution. A tenant is not automatically one person or one database.
- Browser cacheThe browser cache stores suitable HTTP responses for later use. Reuse and revalidation follow the applicable rules.
- Cache invalidationCache invalidation ends reuse of a stored copy under defined rules. The source record remains a separate concern.
Articles on this topic
Software Development with ASES
Custom software, web and mobile apps