Pessimistisk samtidighet
En samtidighetsstrategi som antar att konflikter är troliga och därför låser data i förväg (t.ex. SELECT ... FOR UPDATE), så att andra transaktioner får vänta. "Lås först, arbeta sedan" — motsatsen till optimistisk samtidighet.
Mekanik: innan en transaktion ändrar data tar den ett lås på raderna; andra som vill röra samma rader blockeras tills låset släpps (vid commit/rollback). Vinst: garanterar att ingen annan ändrar datan medan du arbetar → inga överraskningar, ingen "lost update", förutsägbart. Pris: lägre samtidighet (väntan), risk för deadlocks, och dålig passform när konflikter egentligen är sällsynta (då slösar man med lås). Bäst när konflikter är vanliga och det är dyrt att göra om arbete (t.ex. ett banksaldo med hög konkurrens). Motsatsen — optimistisk samtidighet — låter alla köra fritt och upptäcker konflikt först vid commit (versionskontroll / serialiseringsfel), bättre när konflikter är ovanliga. Valet beror på konfliktfrekvensen. Hör ihop med deadlock-detektering och serialiseringsfel.