Bloquear o reintentar

El punto de partida

El episodio anterior terminó con dos formas de impedir que dos cambios a la vez rompan una regla. Una es dejar que la base de datos detecte el choque y reintentar. La otra es no dejar que haya choque: que el segundo espere a que termine el primero.

Son las dos grandes familias del control de concurrencia, y tienen nombre de carácter. El pesimista da por hecho que habrá choques y bloquea antes de tocar nada. El optimista da por hecho que no los habrá, trabaja sin bloquear y comprueba al final.

Un martes y un día 1

Las domiciliaciones han cambiado el ritmo de la cuenta de casa. Un martes cualquiera, los cobros llegan de uno en uno. Pero los recibos se presentan en ficheros, y casi todas las compañías eligen los primeros días del mes: el día 1, cinco recibos y dos pagos llegan en el mismo segundo.

En la simulación, cada operación tiene su barra sobre un eje de tiempo. Una unidad es lo que tarda una operación en leer la cuenta, comprobar el saldo y escribir. Elige el día y lanza los cobros.

Qué ha pasado

• El martes, el optimista gana: nadie choca y nadie espera. El pesimista paga un poco en cada operación por bloquear y desbloquear, aunque no hiciera falta.
• El día 1, el pesimista no falla nunca, pero pone a todos en fila: la última operación espera a las seis anteriores. El optimista se hunde: cada escritura que sale bien invalida el trabajo de todas las que estaban en marcha, los intentos que no valen se encadenan y cuatro operaciones agotan sus intentos.

Ninguno es mejor. El pesimista paga siempre un poco para no fallar nunca; el optimista no paga nada mientras no hay choques, y mucho cuando los hay. Se elige por cuántos choques se esperan, y en el banco eso depende del dato: el contador de Bizum de Laura casi nunca tiene dos escrituras a la vez; la cuenta de casa, el día 1, las tiene seguro.

Y el día 1 no es un accidente: es previsible. El banco puede hacer algo mejor que elegir entre esperar y fallar: procesar los recibos de una misma cuenta en fila, uno detrás de otro, sin bloquear las demás cuentas; o repartir el fichero a lo largo de la mañana. Cuando los choques se pueden prever, se pueden evitar.

Esperarse para siempre

El bloqueo pesimista tiene su propio fallo, y no es lento: es infinito. Laura traspasa 100 € de su cuenta principal a la de casa y, en el mismo instante, Marcos traspasa 50 € de la de casa a la principal de Laura. Cada traspaso tiene que bloquear las dos cuentas.

La simulación dibuja un grafo de espera: los traspasos a la izquierda, las cuentas a la derecha. Una flecha continua sale de la cuenta hacia el traspaso que la tiene bloqueada; una discontinua va del traspaso a la cuenta que espera. Elige en qué orden bloquea cada traspaso.

Un orden para todos

Si cada traspaso bloquea primero la cuenta que lee primero, Laura coge la principal y Marcos la de casa, y cada uno espera la que tiene el otro. Las flechas forman un ciclo, y un ciclo en un grafo de espera significa que nadie va a poder seguir. La base de datos lo detecta, aborta uno de los dos y alguien tiene que reintentarlo.

La solución es tan sencilla que parece trampa: bloquear siempre en el mismo orden, por ejemplo por IBAN. Si todos piden primero la cuenta con el IBAN menor, nadie puede tener la segunda mientras espera la primera, y el ciclo es imposible. Marcos espera un momento, sin haber bloqueado nada, y sigue.

Para llevarse

• El pesimista bloquea antes de leer: siempre hay esperas, nunca hay choques. El optimista comprueba al escribir: sin choques, gratis; con muchos, los reintentos se encadenan.
• Se elige por cuántos choques se esperan, y los choques que se pueden prever se pueden evitar: ordenar o repartir el trabajo.
• Bloquear en distinto orden puede interbloquear. Bloquear siempre en el mismo orden lo hace imposible.

Hasta aquí, el banco ha luchado por que todo el mundo vea el mismo dato al mismo tiempo. El siguiente episodio va de lo contrario: de un sitio donde el banco decide, a propósito, no estar de acuerdo consigo mismo durante días.