Koncepcja zamków prowadzi do nieprzyjemnego efektu zwanego zakleszczeniem.

Transakcja A zablokowała zasób X i żąda dostępu do zasobu Y

Transakcja B zablokowała zasób Y i żąda dostępu do zasobu X. Ani A,

ani B nie mogą dalej kontynuować jakiejkolwiek akcji. (System “zawiesił się’.)

Możliwe są bardziej skomplikowane sytuacje związane z zakleszczeniem:

W pętli zakleszczenia są 3 transakcje	Zakleszczyły się dwie transakcje, pozostałe działają normalnie:

Bardzo poważny problem, mający skutki zarówno dla wydajności systemu jak i spójności działania (szczególnie w systemach czasu rzeczywistego, np. w bankach).

1. Wykrywanie zakleszczeń i rozrywanie pętli zakleszczenia. Detekcja zakleszczenia wymaga skonstruowania grafu czekania (wait-for graph) i tranzytywnego domknięcia tego grafu (złożoność gorsza niż n * n). Rozrywanie pętli zakleszczenia polega na wybraniu transakcji “ofiary” uczestniczącej w zakleszczeniu i następnie, jej zerwaniu i uruchomieniu od nowa. Wybór “ofiary” podlega różnym kryteriom - np. najmłodsza, najmniej pracochłonna, o niskim priorytecie, itd.
2. Nie dopuszczanie do zakleszczeń. Istnieje wiele tego rodzaju metod, np.
   1. Wstępne żądanie zasobów (preclaiming): przed uruchomieniem każda transakcja określa potrzebne jej zasoby. Nie może później nic więcej żądać. Wada: zgrubne oszacowanie żądanych zasobów prowadzi do zmniejszenia stopnia współbieżności.
   2. Czekasz-umieraj (wait-die): jeżeli transakcja próbuje dostać się do zasobu, który jest zablokowany, to natychmiast jest zrywana i powtarzana od nowa. Metoda może być nieskuteczna dla systemów interakcyjnych (użytkownik może się denerwować koniecznością dwukrotnego wprowadzania tych samych danych) oraz prowadzi do spadku efektywności (sporo pracy idzie na marne).