¿Qué puede salir mal al usar transacciones en una base de datos?

Nota: Este es un extracto de una versión sin editar de mi libro MariaDB for Developers.

Hasta este punto, hemos comprendido el concepto de atomicidad: o todas las operaciones se completan correctamente, o ninguna lo hace. ¿Qué puede salir mal? Parece que todo está cubierto. Y lo está. Hasta que introducimos concurrencia en nuestro sistema. MariaDB es uno de los sistemas de bases de datos más eficientes y trata de paralelizar el procesamiento para aumentar el rendimiento. Paralelizar significa que MariaDB puede ejecutar transacciones de diferentes sesiones al mismo tiempo intercalando operaciones de diferentes transacciones, en lugar de esperar a que una termine para empezar la siguiente. Cada transacción tiene su propia secuencia de operaciones, pero MariaDB las ejecuta en orden superpuesto. La figura 8-2 muestra dos transacciones (A y B) y múltiples operaciones intercaladas a lo largo del tiempo.

Este intercalado permite que MariaDB use los recursos de CPU y E/S de manera más eficiente que sin paralelismo. Sin embargo, esto abre la puerta a problemas sutiles cuando las transacciones paralelas leen y escriben datos que se sobrelapan. Estudiemos algunos de estos problemas conocidos como fenómenos de concurrencia.

Lecturas sucias

#

¡Viernes por la tarde y tenemos un ganador! Nuestra aplicación de tareas—que para el capítulo 6 ya se había convertido más en una herramienta de gestión de proyectos que en una simple lista de pendientes—es tan central para el negocio que se otorgan premios a los usuarios que se destacan reportando errores o ayudando en su desarrollo. Nuestra aplicación permite al equipo de RRHH otorgar premios a usuarios, y este caso de uso implica reducir la cantidad del premio otorgado en la tabla prizes.

Janet y Moe, ambos del equipo de RRHH, están usando la aplicación al mismo tiempo. Janet está a punto de otorgar el premio del día (llamado “Bagelers” en nuestra base de datos), mientras Moe está viendo un panel que muestra un resumen del inventario de premios. Janet selecciona al ganador y el premio, y hace clic en “Otorgar premio”. Nuestra aplicación inicia una nueva transacción que reduce la cantidad de Bagelers de 8 a 7. En ese momento, Moe actualiza el panel y ve que hay 7 Bagelers. Sin embargo, el sistema se cae y, como la transacción nunca fue confirmada, la nueva cantidad no se guarda en disco. Janet recibe un error, pero Moe no. Para él, hay 7 Bagelers. Está viendo datos incorrectos. Esto se llama una lectura sucia. La figura 8-3 muestra una secuencia de operaciones que llevan a una lectura sucia en el tiempo t₃.

Lecturas no repetibles

#

Una situación similar puede ocurrir cuando una transacción lee un valor dos veces, pero dicho valor es modificado entre las lecturas por otra transacción. En este caso, la segunda lectura obtendría un valor distinto. Este fenómeno se llama lectura no repetible y puede llevar a resultados incorrectos si los valores son usados para otros cálculos dentro de la misma transacción. La figura 8-4 muestra una lectura no repetible en el tiempo t₅.

Lecturas fantasma

#

Si la operación de escritura en el ejemplo anterior implica insertar filas, obtenemos lo que se conoce como el fenómeno de lectura fantasma. La figura 8-5 muestra una lectura fantasma en el tiempo t₅.

¿Quieres profundizar más en temas como este sobre bases de datos? Estoy escribiendo un libro sobre MariaDB que cubre SQL, transacciones, índices, y muchos otros temas prácticos que los desarrolladores deben conocer. Échale un vistazo aquí si te interesa.