Bloqueos, esperas y el error que todos conocen

Qué significa

Significa que alguien más tiene el cerrojo de escritura y tu operación no ha podido tomarlo en el tiempo de espera configurado. Y «alguien más» tiene cuatro identidades posibles:

Fíjate en que ninguna de las cuatro se arregla reintentando. El reintento oculta la primera y la segunda —que son fallos— y hace lo mismo que el tiempo de espera para la tercera, pero peor y con más código.

La primera, que es la más frecuente

Merece detalle porque es específica de escritorio y sorprende a quien viene de servidores:

Y la segunda fila de la derecha es el argumento de fondo: aunque los bloqueos se resolvieran, dos instancias sobre la misma base es un problema de coherencia, no de cerrojos. La respuesta es instancia única.

La segunda: transacciones que no se cierran

El fallo de código que produce este error, y tiene una forma reconocible:

// mal: si algo falla en medio, la transacción se queda abiertalet tx = conn.transaction()?;hacer_algo(&tx)?;          // si esto devuelve error, se sale sin cerrartx.commit()?;

En Rust esto suele estar bien —la transacción se descarta al salir del ámbito— y se rompe cuando alguien la guarda en una estructura, la pasa por ahí, o la mantiene abierta mientras espera algo. La regla: una transacción vive dentro de una función y no sale de ella. Si te ves guardándola en un campo, es señal de que el diseño va a producir este error.

Configurar la espera

El ajuste del nivel 41.2, con criterio:

• Unos segundos está bien para una aplicación de escritorio. Cubre las coincidencias legítimas sin que el usuario note nada.
• Cero es malo —falla al instante ante cualquier coincidencia— y muy alto también: convierte un error rápido en una interfaz congelada durante medio minuto.
• Y si con unos segundos sigue fallando, no lo subas: busca cuál de las cuatro causas es. Un tiempo de espera alto es una tirita sobre un problema estructural.