Las transacciones serializables como problema de preservación de invariantes

Partir de una propiedad de los datos

Supongamos que un equipo debe conservar al menos un revisor disponible. Dos registros indican si el revisor A y el revisor B están disponibles. Una transacción solo puede hacer que su propio revisor deje de estar disponible si otro revisor permanece disponible. Por tanto, el invariante es una propiedad del par de registros, no de cada fila por separado. Una base de datos puede proteger cada actualización individual frente a la corrupción y, aun así, permitir que el par alcance un estado no válido.

El ejemplo se generaliza a límites de capacidad, relaciones entre cuentas y reglas de admisión. Antes de seleccionar un nivel de aislamiento, quien diseña el sistema debe especificar los estados permitidos y demostrar que cada transacción los preserva cuando se ejecuta sola. Sin ese primer paso, incluso una ejecución serial perfecta puede ser incorrecta. El aislamiento puede limitar la interferencia; no puede reparar una transacción cuya lógica secuencial ya vulnera la regla de negocio.

Qué aporta la bibliografía seleccionada

Berenson y sus colegas muestran por qué una lista reducida de fenómenos SQL con nombre no caracteriza adecuadamente el comportamiento del aislamiento y otorgan al aislamiento por instantáneas un papel preciso en esa discusión. Fekete y sus colegas desarrollan condiciones en las que las transacciones con aislamiento por instantáneas pueden producir ejecuciones no serializables, poniendo el énfasis en razonar sobre la estructura de dependencias de la aplicación. Ports y Grittner describen la ingeniería del aislamiento serializable por instantáneas en PostgreSQL, incluido el seguimiento de conflictos, las consideraciones de memoria acotada y el tratamiento especial de las transacciones de solo lectura.

El artículo histórico sobre PostgreSQL trata de la implementación y los experimentos que presenta, no de todas las versiones o configuraciones posteriores. Lo citamos por el mecanismo y las obligaciones de ingeniería, en lugar de trasladar sus resultados de pruebas de rendimiento. En conjunto, las fuentes motivan una pregunta más exigente que si una base de datos utiliza almacenamiento multiversión: ¿qué historiales concurrentes puede observar la aplicación? [1], [2], [3]

El testigo mínimo de sesgo de escritura

Partimos de A y B disponibles. La transacción T_A lee ambos registros y planea desactivar la disponibilidad de A; la transacción T_B lee el mismo estado inicial y planea desactivar la de B. Sus conjuntos de escritura son disjuntos. Una política que rechaza únicamente escrituras concurrentes solapadas no tiene por qué abortar ninguna de las dos transacciones. La confirmación de ambas deja al equipo sin ningún revisor disponible.

La instantánea de ninguna transacción era internamente incoherente, y ninguna sobrescribió la fila de la otra. El fallo surge porque cada decisión se apoyó en un valor que la otra transacción modificó. En cualquiera de los dos órdenes secuenciales, la segunda transacción vería que ya no está permitido desactivar la disponibilidad de su revisor. Por tanto, el resultado concurrente no tiene una ejecución serial equivalente de estas transacciones. El ejemplo finito proporcionado compara esos dos órdenes seriales con la ejecución de instantáneas solapadas y comprueba directamente el invariante.

Las dependencias explican más que los conflictos entre filas

Un grafo de dependencias describe restricciones de orden entre transacciones. La lectura de una versión anterior puede imponer una restricción de orden a una transacción respecto de otra que crea una versión posterior; esto es una antidependencia de lectura-escritura. En el testigo de los dos revisores, cada transacción lee un valor invalidado por la otra, lo que produce un ciclo. Los conjuntos de escritura disjuntos ocultan ese ciclo a una simple comprobación de conflictos de escritura-escritura.

Un algoritmo de serialización en producción no necesariamente construye todas las aristas ni busca en un grafo completo. La detección conservadora puede abortar historiales que finalmente habrían sido serializables. Por tanto, el número de abortos no es un recuento de vulneraciones reales del invariante que se hayan evitado, ni una estimación directa de la probabilidad de historiales inseguros de una carga de trabajo. Es un resultado del algoritmo, de la temporización y de la información retenida. Evaluar la implementación exige separar ese mecanismo conservador del criterio abstracto de dependencias. [2], [3]

Un modelo construido de retirada concurrente

Extendamos el ejemplo a n revisores disponibles. Las n transacciones toman la misma instantánea inicial; cada una decide de forma independiente retirarse con probabilidad p y escribe únicamente en su propia fila. Para n mayor o igual que dos, cada retirada observa otro revisor inicialmente disponible. El invariante final falla exactamente cuando se retiran todos los revisores, lo que da una probabilidad de p elevado a n en esta construcción deliberadamente síncrona.

Con p igual a un medio, las probabilidades de fallo para dos, cuatro y ocho revisores son un cuarto, un dieciseisavo y un doscientos cincuenta y seisavo. Esta no es una fórmula general para el sesgo de escritura. Depende de instantáneas iniciales idénticas, decisiones independientes, el invariante concreto y la ausencia de una protección adicional. La figura es útil porque hace explícitos los supuestos; una estimación para un despliegue requeriría un modelo del solapamiento y de las decisiones reales de las transacciones.

Qué ofrece la serializabilidad y qué no

Si el estado inicial satisface el invariante y cada transacción lo preserva de forma aislada, una ejecución serial equivalente lo preserva por inducción. Esta es una forma potente de reducir el razonamiento concurrente a razonamiento secuencial. La implicación depende de que los límites de las transacciones abarquen todas las lecturas y escrituras pertinentes, y de que todas las operaciones participantes respeten el contrato.

La serializabilidad por sí sola no exige que el orden serial respete la precedencia en tiempo real de las operaciones del cliente que no se solapan. La serializabilidad estricta añade esa condición. Un informe que solo diga «serializable» no debe prometer implícitamente una lectura entre regiones inmediatamente actualizada después de una escritura reconocida. Tampoco se extiende automáticamente la garantía de la base de datos a una caché, un índice de búsqueda o un mensaje externo ya enviado. Estos componentes necesitan su propia justificación de visibilidad y recuperación.

Los reintentos forman parte de la semántica de la aplicación

Por lo general, una transacción abortada debe reintentarse a partir de una nueva lectura del estado pertinente. Repetir únicamente la escritura final conserva la decisión obsoleta y anula el propósito del aborto. Si la transacción envía un correo electrónico o realiza un cobro en un servicio externo antes de confirmarse, volver a ejecutar toda la función de la aplicación puede repetir ese efecto aunque la propia transacción de la base de datos se haya revertido.

Por tanto, un diseño seguro ante reintentos distingue entre cálculo provisional, estado confirmado y entrega externa. Una bandeja de salida duradera puede registrar un efecto previsto en la misma transacción que el cambio de estado, pero la entrega sigue necesitando una identidad y un contrato compatible del consumidor. Esta conexión explica por qué el aislamiento y los efectos exactamente una vez no pueden revisarse de forma independiente en el límite de una aplicación. El número de transacciones exitosas puede ser correcto mientras el usuario recibe dos confirmaciones de una única operación aceptada.

La amplificación por abortos tiene un denominador

Para un modelo estacionario ilustrativo, supongamos que cada intento aborta de manera independiente con probabilidad a y que un intento exitoso termina el bucle de reintentos. El número esperado de intentos por éxito es uno dividido entre la diferencia entre uno y a. Con una probabilidad de aborto de un medio, un éxito lógico consume dos intentos en promedio; con nueve décimos, consume diez. La figura muestra intentos, no tiempo transcurrido ni coste de CPU.

Los reintentos reales no son independientes. Los reintentos inmediatos pueden permanecer sincronizados, los abortos pueden consumir menos trabajo que las confirmaciones y la espera entre reintentos modifica tanto la carga ofrecida como la latencia. No obstante, el modelo identifica una obligación de presentación de resultados: la tasa de procesamiento debe contar operaciones lógicas completadas, mientras que las mediciones de recursos deben incluir todos los intentos. Contar las transacciones intentadas como trabajo útil puede hacer que un sistema con muchos abortos parezca rápido aunque proporcione poco progreso a los usuarios.

Lecturas por predicado y niveles de aislamiento mixtos

El ejemplo de los revisores utiliza dos filas identificadas, pero muchos invariantes se refieren a la ausencia de una fila o al número total de filas que satisfacen un predicado. Una inserción concurrente puede invalidar una transacción que comprueba si queda alguna plaza. Proteger únicamente las filas que casualmente devolvió la consulta no protege necesariamente la decisión.

Los niveles de aislamiento mixtos también complican una demostración que, de otro modo, sería clara. Si una transacción utiliza una vía serializable, pero otro escritor la elude bajo un contrato más débil, la aplicación no puede inferir un historial global serializable solo a partir de la etiqueta de la primera transacción. Los trabajos de mantenimiento, las importaciones administrativas y los procesos en segundo plano deben formar parte del inventario de transacciones. El ámbito pertinente de la demostración es el conjunto de operaciones que pueden modificar el invariante, no el subconjunto que casualmente utiliza el punto de acceso preferido de la aplicación. [1], [3]

Un diseño de pruebas centrado en invariantes falsables

Construya historiales pequeños con barreras entre lecturas y escrituras para que las decisiones solapadas se produzcan de forma fiable. Compruebe mediante aserciones el invariante de los datos después de cada prefijo confirmado y tras la recuperación de un fallo. Registre la versión de la base de datos, el ajuste de aislamiento de las transacciones, el esquema, las restricciones de unicidad, los planes de consulta cuando sean pertinentes y el bucle completo de reintentos. Incluya un control que utilice deliberadamente la política más débil y exhiba el testigo conocido.

Después, varíe la contención, el sesgo, la duración de las transacciones y la selectividad de los predicados, manteniendo la misma carga de trabajo lógica. Informe de los éxitos útiles, las causas de aborto, el coste por intento y la latencia de extremo a extremo. Un resultado rápido que cambia el invariante o descarta silenciosamente solicitudes fallidas corresponde a otra carga de trabajo. La afirmación científica es más sólida cuando el lector puede reconstruir tanto el fallo como el mecanismo que lo excluye, en lugar de limitarse a observar un gran número total de operaciones que superaron las pruebas.

Conclusión: el aislamiento es una promesa composicional

El beneficio central de la serializabilidad es la reducción de la complejidad del razonamiento, siempre que la aplicación defina transacciones secuenciales correctas y mantenga todos los efectos pertinentes dentro de un límite gestionado explícitamente. La coherencia de las instantáneas, la prevención de conflictos a nivel de fila y una prueba de estrés exitosa son, cada una, hechos de alcance más limitado.

El testigo desarrollado y el modelo probabilístico muestran cómo un invariante pequeño y preciso puede revelar una brecha que las pruebas generales de tasa de procesamiento pasan por alto. El modelo de reintentos muestra por qué corregir esa brecha puede alterar la cantidad de trabajo necesaria por resultado útil. Una evaluación defendible debe preservar el invariante y contabilizar ese trabajo al mismo tiempo. Esta visión conjunta convierte una etiqueta de aislamiento en un contrato de aplicación comprobable.

Ejecutado localmente · Alcance acotado

Sesgo de escritura con instantáneas frente a ambos órdenes seriales

Dos transacciones sobre filas disjuntas en una máquina de estados de juguete; no se ejecutó ningún motor de base de datos.

Se superaron 3 aserciones. Estas comprobaciones validan el ejemplo proporcionado, no los sistemas citados.

{
  "snapshot_final": [
    0,
    0
  ],
  "serial_finals": [
    [
      0,
      1
    ],
    [
      1,
      0
    ]
  ]
}

Descargar los 20 ejemplos ejecutablesLeer los resultados completos de las comprobaciones

Un modelo analítico declarado

Cuatro ecuaciones, supuestos explícitos

Ejemplos construidos · Datos reproducibles

Inspeccionar el argumento cuantitativo

Estas curvas se calculan a partir de los modelos declarados. No son observaciones de los estudios citados. Cada figura incluye sus datos numéricos y su versión vectorial.

Descargar CSVDescargar el archivo fuente SVGReproducir con Python

Descargar CSVDescargar el archivo fuente SVGReproducir con Python

¿Qué evidencia responde a cada pregunta?

Un protocolo de validación propuesto

Este es un diseño de evaluación propuesto. No se realizó ninguna prueba de rendimiento de sistemas en producción ni de hardware. Los modelos finitos ejecutados por separado están documentados en las comprobaciones ejecutables.

1. Codifique el invariante de la aplicación como una aserción independiente de la implementación de las transacciones.
2. Ejecute el testigo de dos transacciones con barreras explícitas y conserve el orden completo de los eventos.
3. Verifique ambos órdenes seriales como control positivo.
4. Repita con el contrato de aislamiento previsto y verifique que, en los historiales inseguros, no puedan confirmarse ambas transacciones en la prueba.
5. Inyecte abortos en cada límite de efectos de la aplicación e inspeccione las identidades de las operaciones lógicas.
6. Mida las operaciones lógicas exitosas, todos los intentos, la latencia y el uso de recursos bajo la misma carga de trabajo.

Qué establecen las fuentes primarias

Límites de este análisis

• La figura de probabilidades es específica de retiradas simultáneas e independientes; no es una tasa de anomalías medida.
• El modelo de reintentos omite la dependencia, los reintentos acotados, los costes desiguales de los intentos y la espera entre reintentos.
• El testigo finito no pone a prueba una instancia instalada de PostgreSQL ni ningún producto actual de base de datos.
• Se comprobaron la identidad y el resumen de la fuente de Fekete; no se recuperó su texto original completo en esta sesión.

Una revisión analítica focalizada de tres fuentes primarias fundacionales seleccionadas, con ejemplos desarrollados originales. No es una revisión exhaustiva ni sistemática de la bibliografía hasta 2026. Las notas sobre acceso a las fuentes y versiones se registran junto con la bibliografía.

Preguntas que cambiarían la conclusión

1. ¿Qué escritores o efectos externos quedan fuera del límite previsto de la transacción?
2. ¿Cómo interactúan el seguimiento de dependencias y la política de reintentos bajo una contención sesgada?
3. ¿Qué invariantes de la aplicación requieren orden en tiempo real además de serializabilidad?

Referencias

1. Hal Berenson, Phil Bernstein, Jim Gray et al.. A critique of ANSI SQL isolation levels. Proceedings of the 1995 ACM SIGMOD international conference on Management of data - SIGMOD '95 (1995). 10.1145/223784.223785.
2. Alan Fekete, Dimitrios Liarokapis, Elizabeth O'Neil et al.. Making snapshot isolation serializable. ACM Transactions on Database Systems (2005). 10.1145/1071610.1071615.
3. Dan R. K. Ports, Kevin Grittner. Serializable snapshot isolation in PostgreSQL. Proceedings of the VLDB Endowment (2012). 10.14778/2367502.2367523.

Acceso a la fuente [1]. Registro primario, resumen y texto accesible seleccionado; no es una auditoría exhaustiva del texto completo ni del material suplementario.

Acceso a la fuente [2]. Artículo original publicado alojado por la Universidad de Minnesota; se inspeccionaron el teorema 2.1 y la discusión sobre sesgo de escritura. Se trata de una comprobación de texto seleccionado, no de una auditoría completa de la demostración.

Acceso a la fuente [3]. Registro primario, resumen y texto accesible seleccionado; no es una auditoría exhaustiva del texto completo ni del material suplementario.

Las identidades bibliográficas se contrastaron con Crossref y con registros primarios del editor, los autores o las instituciones. Las notas siguientes sobre acceso a las fuentes y versiones describen el alcance; no se trata de una auditoría exhaustiva de los textos completos.

Autoría y procedencia

Escrito y sometido a autorrevisión técnica por Codex (IA). Las referencias identifican a los investigadores originales; las construcciones analíticas y los diseños de evaluación propuestos se atribuyen a este artículo.

Las portadas son ilustraciones conceptuales de ImageGen. Las figuras técnicas se calculan a partir de modelos declarados o ejemplos finitos, con Python y CSV incluidos. No son mediciones de productos desplegados ni reproducciones de pruebas de rendimiento.

Este borrador local no cuenta con un registro de revisión por pares independiente ni de aceptación en una revista. Los ejemplos ejecutables acotados comprueban los pequeños modelos expuestos; no constituyen una verificación formal de los sistemas citados.