Antiguo y abandonado blog de Ricardo Galli :-(

Para los que hayan estudiado informática (o sean buenos programadores ) les sonará el término deadlock, o “interbloqueo”, o “abrazo mortal”. Es una situación que se puede producir en la compartición de recursos de un ordenador cuando muchos procesos intentan acceder a recursos compartidos y se llega a una situación de “bucle” (es en grafo de asignación) en el que ningún proceso puede continuar porque está esperando recursos asignados a otro que a su vez también espera que se liberen otros recursos…

Hay muchos métodos para evitar que se produzcan los interbloqueos, desde prevenirlo evitando que se produzca una de las cuatro condiciones necesarias:

1. exclusión mutua,
2. retención y espera (hold and wait),
3. no apropiativo (no preemption),
4. espera circular (circular wait).

Muchas veces no es posible evitar que se produzcan esas condiciones y se deben tomar otras medidas más complejas:

1. Prevención dinámica: en cada solicitud de recursos se verifica si la satisfacción de esa asignación podría llevar a una situación “peligrosa” de interbloqueo. Aquí se usan algoritmos o técnicas similares y derivadas del algoritmo del banquero.

2. Detección y recuperación: otra forma es detectar cuando se ha producido un interbloqueo mediante técnicas de detección de bucles en un grafo. Es un poco más complejo (fundamentalmente de complejidad O(n^2)) por lo que se usan simplificaciones –por ejemplo poniendo tiempos de expiración a los bloqueos–. El problema es cómo “recuperarse” de un interbloqueo, no es nada simple. Hay dos técnicas fundamentales:

   a. Matar a unos o varios de los procesos involucrados en el interbloqueo. De esta forma se “rompería” la espera circular y los demás procesos podrían continuar. Este tipo de soluciones es subóptima, ya que es muy difícil escoger al proceso adecuado (lo que pasaba con el Out of Memory Killer del Linux, que era una forma de soluciones el interbloqueo generado por la falta de memoria) y además producen que se acaben procesos de forma errónea.

   b. Vuelta atrás o roll back. Esta técnica se basa en retornar el estado del proceso a uno anterior conocido y luego dejarlo continuar. Es muy difícil hacerlo en un sistema operativo genérico, pero es un área muy conocida y usada en las bases de datos transaccionales.

¿A qué viene todo este rollo? Al siguiente mensaje que me encontré varias veces en una página web enlazada desde Slashdot:

Microsoft OLE DB Provider for ODBC Drivers error ‘80004005′ [Microsoft][ODBC SQL Server Driver][SQL Server]Transaction (Process ID 156) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction. /efytimes/lefthome.asp, line 193

Me llamó mucho la atención por varios motivos:

1. El problema en este caso era claramente una “sobrecarga” de la base de datos. En estos caso lo que suele ocurrir es una “espera infinita” (o starvation) y no un interbloqueo.

2. El tiempo entre el acceso a la página y el mensaje que obtenía era muy corto y se cargaba rápidamente, por lo que quizás no era una espera infinita sino de un interbloqueo de verdad que haya sido detectado por la base de datos (en este caso SQL Server).

3. Que una base de datos transaccional tenga problemas de deadlocks con un caso tan sencillo de consultas para generar una página web. Quizás tengan alguna actualización para registrar accesos, pero en todo caso ésta debería ser independiente de las consultas para generación por lo que:

   1. La página se podría haber generado igualmente y ocultar el error al visitante.

   2. EL SQL Server o el programa de la página web tiene un serio problema en las actualizaciones.

En todo caso esto me recuerda nuevamente a que “no hay soluciones mágicas”, muchas veces los sistemas más complejos y sofisticados no son lo mejor para tareas sencillas como generar una página web. Lo que explica en gran parte el porqué la base de datos MySQL se hizo tan popular en servicios web aún cuando no tenía ni los mínimos requisitos para ser una base de datos ACID. También explica porqué se sigue usando mucho el motor MyISAM (sin locks por filas ni transacciones) en vez del InnoDB que sí tiene todas las características transaccionales (y rollback por interbloqueos).

Y por otro lado me recuerda lo estúpido que pueden ser los presuntos “mensajes de error ultra explicativos”. ¿Cuántos lectores entenderían ese mensaje?

Es más, ¿cuántos “informáticos” o presuntos geeks lo entenderían correctamente?

Pues eso, que este apunte sirva para entusiasmar a estudiar esa “informática dura” pero que en realidad es la más divertida… o al menos tenga valor didáctico para entender los mensajes tan guais del SQL Server