Optimistic Locking is een strategie waarbij u een record leest, een versienummer noteert (andere methoden om dit te doen zijn datums, tijdstempels of checksums/hashes) en controleert of de versie niet is gewijzigd voordat u het record terugschrijft. Wanneer u de record terugschrijft, filtert u de update op de versie om er zeker van te zijn dat deze atomair is. (d.w.z. niet is bijgewerkt tussen het moment dat u de versie controleert en het record naar de schijf schrijft) en de versie in één keer bijwerkt.
Als het record vuil is (d.w.z. een andere versie dan de uwe), annuleert u de transactie en kan de gebruiker deze opnieuw starten.
Deze strategie is het meest van toepassing op systemen met een hoog volume en architecturen met drie lagen, waarbij u niet noodzakelijkerwijs een verbinding met de database onderhoudt voor uw sessie. In deze situatie kan de client de databasevergrendelingen niet daadwerkelijk handhaven, omdat de verbindingen uit een pool worden gehaald en u mogelijk niet dezelfde verbinding van de ene toegang naar de andere gebruikt.
Pessimistische vergrendeling is wanneer u het record vergrendelt voor exclusief gebruik totdat u ermee klaar bent. Het heeft een veel betere integriteit dan optimistische vergrendeling, maar vereist dat u voorzichtig bent met uw toepassingsontwerp om Deadlocks te voorkomen. Om pessimistische vergrendeling te gebruiken, hebt u ofwel een directe verbinding met de database nodig (zoals gewoonlijk het geval is in een client-servertoepassing met twee niveaus) of een extern beschikbare transactie-ID die onafhankelijk van de verbinding kan worden gebruikt.
In het laatste geval opent u de transactie met de TxID en maakt u vervolgens opnieuw verbinding met die ID. Het DBMS onderhoudt de vergrendelingen en stelt u in staat om de sessie weer op te halen via de TxID. Dit is hoe gedistribueerde transacties met behulp van tweefasige commit-protocollen (zoals XA- of COM+-transacties) werken.