Concurrencia pesimista
Estrategia de concurrencia que asume que los conflictos son probables y por eso bloquea los datos de antemano (p. ej. SELECT ... FOR UPDATE), obligando a otras transacciones a esperar. "Primero bloquear, después trabajar" — lo contrario de la concurrencia optimista.
Mecánica: antes de modificar datos, la transacción toma un bloqueo sobre las filas; cualquier otra que quiera tocar esas mismas filas se bloquea hasta que el bloqueo se libera (al hacer commit o rollback). Ventaja: garantiza que nadie más cambie los datos mientras se trabaja con ellos → sin sorpresas, sin "lost update", comportamiento predecible. Coste: menor concurrencia (hay que esperar), riesgo de deadlocks, y mal encaje cuando los conflictos son en realidad poco frecuentes (entonces se desperdician bloqueos). Funciona mejor cuando los conflictos son habituales y rehacer el trabajo sale caro (por ejemplo, un saldo bancario con mucha contención). Lo contrario —la concurrencia optimista— deja que todos avancen libremente y solo detecta el conflicto al hacer commit (control de versiones o fallo de serialización), lo cual funciona mejor cuando los conflictos son raros. La elección depende de la frecuencia de conflicto real. Relacionado con la detección de interbloqueos y el fallo de serialización.