Optimistisk låsning er en strategi, hvor du læser en post, noterer et versionsnummer (andre metoder til at gøre dette involverer datoer, tidsstempler eller kontrolsummer/hash) og kontrollerer, at versionen ikke er ændret, før du skriver posten tilbage. Når du skriver posten tilbage, filtrerer du opdateringen på versionen for at sikre, at den er atomær. (dvs. ikke er blevet opdateret mellem det tidspunkt, hvor du tjekker versionen og skriver posten til disken) og opdaterer versionen med et enkelt hit.
Hvis posten er snavset (dvs. en anden version end din), afbryder du transaktionen, og brugeren kan genstarte den.
Denne strategi er mest anvendelig til højvolumensystemer og trelagsarkitekturer, hvor du ikke nødvendigvis opretholder en forbindelse til databasen for din session. I denne situation kan klienten faktisk ikke opretholde databaselåse, da forbindelserne tages fra en pulje, og du muligvis ikke bruger den samme forbindelse fra den ene adgang til den anden.
Pessimistisk låsning er, når du låser pladen til eget brug, indtil du er færdig med den. Det har meget bedre integritet end optimistisk låsning, men kræver, at du er forsigtig med dit applikationsdesign for at undgå dødvande. For at bruge pessimistisk låsning skal du enten have en direkte forbindelse til databasen (som det typisk vil være tilfældet i en to-tiers klientserverapplikation) eller et eksternt tilgængeligt transaktions-id, der kan bruges uafhængigt af forbindelsen.
I sidstnævnte tilfælde åbner du transaktionen med TxID'et og genopretter forbindelsen med dette id. DBMS vedligeholder låsene og giver dig mulighed for at hente sessionen op igen gennem TxID. Sådan fungerer distribuerede transaktioner, der bruger tofasede commit-protokoller (såsom XA- eller COM+-transaktioner).