Optimistisk låsning är en strategi där du läser en post, noterar ett versionsnummer (andra metoder för att göra detta är datum, tidsstämplar eller kontrollsummor/hash) och kontrollerar att versionen inte har ändrats innan du skriver tillbaka posten. När du skriver tillbaka posten filtrerar du uppdateringen på versionen för att se till att den är atomär. (dvs. har inte uppdaterats mellan det att du kontrollerar versionen och skriver posten till disken) och uppdaterar versionen i en träff.
Om posten är smutsig (dvs. en annan version än din) avbryter du transaktionen och användaren kan starta om den.
Denna strategi är mest tillämpbar på högvolymsystem och treskiktsarkitekturer där du inte nödvändigtvis har en anslutning till databasen för din session. I den här situationen kan klienten faktiskt inte upprätthålla databaslås eftersom anslutningarna tas från en pool och du kanske inte använder samma anslutning från en åtkomst till en annan.
Pessimistisk låsning är när du låser skivan för eget bruk tills du är klar med den. Den har mycket bättre integritet än optimistisk låsning men kräver att du är försiktig med din applikationsdesign för att undvika dödlägen. För att använda pessimistisk låsning behöver du antingen en direkt anslutning till databasen (som vanligtvis skulle vara fallet i en klientserverapplikation med två nivåer) eller ett externt tillgängligt transaktions-ID som kan användas oberoende av anslutningen.
I det senare fallet öppnar du transaktionen med TxID och återansluter sedan med det ID:t. DBMS underhåller låsen och låter dig hämta sessionen tillbaka genom TxID. Så här fungerar distribuerade transaktioner som använder två-fas commit-protokoll (som XA- eller COM+-transaktioner).