Оптимистичното заключване е стратегия, при която четете запис, отбелязвате номера на версията (другите методи за това включват дати, времеви марки или контролни суми/хешове) и проверявате дали версията не се е променила, преди да запишете записа обратно. Когато пишете записа обратно, филтрирате актуализацията на версията, за да сте сигурни, че е атомарна. (т.е. не е актуализиран между момента, в който проверите версията и запишете записа на диска) и актуализирайте версията с едно натискане.
Ако записът е мръсен (т.е. различна версия от вашата), прекратявате транзакцията и потребителят може да я стартира отново.
Тази стратегия е най-приложима за системи с голям обем и тристепенни архитектури, където не е задължително да поддържате връзка с базата данни за вашата сесия. В тази ситуация клиентът всъщност не може да поддържа заключвания на база данни, тъй като връзките са взети от пул и може да не използвате една и съща връзка от един достъп до следващия.
Песимистичното заключване е, когато заключите записа за ваша изключителна употреба, докато не приключите с него. Той има много по-добра цялост от оптимистичното заключване, но изисква от вас да внимавате с дизайна на приложението си, за да избегнете застой. За да използвате песимистично заключване, имате нужда или от директна връзка с базата данни (както обикновено се случва в двустепенно клиентско сървърно приложение) или от външен достъпен идентификатор на транзакция, който може да се използва независимо от връзката.
В последния случай отваряте транзакцията с TxID и след това се свързвате отново, като използвате този ID. СУБД поддържа ключалките и ви позволява да вземете сесията обратно чрез TxID. Ето как работят разпределените транзакции, използващи двуфазни протоколи за commit (като XA или COM+ транзакции).
