cómo Qué es una transacción de base de datos
Imagina que envías diez a un amigo. Restas diez de tu saldo y sumas diez al de tu amigo. Ambas cosas deben ocurrir para que sea correcto. Pero si la resta pasa y la luz se corta justo antes de la suma? Tu dinero se fue y tu amigo no recibió nada. Para evitar esos accidentes, tratar varios cambios como un solo paquete es una transacción.
Una transferencia es una resta y una suma, un par
Antes aprendimos que una base de datos
es un almacén que guarda info a salvo.
Pero a veces no es una cosa la que cambiar,
hay que cambiar dos juntas.
Una transferencia es justo eso.
Quitas dinero de tu saldo
y sumas lo mismo al saldo del receptor.
Estas dos son un par que no puedes separar.
Si solo ocurre una, el accidente llega al instante.
Toca la resta y la suma por separado. Si pulsas solo una, el dinero desaparece o surge de la nada.
Pulsa solo la resta y tu dinero se fue.
Pulsa solo la suma y aparece dinero de la nada.
Ninguna de las dos está bien.
La suma total del dinero ha cambiado.
Ese corto hueco entre la resta y la suma,
justo ahí está el tramo peligroso.
Si algo se cuela en ese hueco
el libro de cuentas se descuadra.
Por eso necesitamos atar las dos.
Todo ocurre, o nada ocurre
El arreglo es sorprendentemente simple.
Junta la resta y la suma en uno.
Este paquete se llama transacción.
Cada cambio dentro del paquete es tentativo.
Solo cuando todos terminan se aplica de verdad, de una vez,
y si uno solo falla, todos se cancelan.
Así nunca queda nada a medias.
Todo ocurre, o nada ocurre.
El estado intermedio no se le muestra a nadie.
Ejecútala como un paquete. Se confirma solo cuando ambos cambios están listos, y cancelar quita los dos.
Ambos se confirman juntos, así que la suma cuadra justo.
Pulsa cancelar y los dos se borran limpiamente.
De cualquier modo el total se mantiene.
Solo por tratarlo como un paquete
ese hueco peligroso desapareció.
Manejado así, todo o nada,
el libro jamás puede descuadrarse.
Pero qué pasa si, a mitad del trabajo dentro del paquete,
la luz de verdad se corta?
Aun cortado, revierte todo
Dijimos que los cambios del paquete son tentativos.
Esa tentatividad es justo la salvaguarda.
No olvida el estado de antes de empezar el trabajo,
lo anota aparte.
Así, aunque la luz muera a medias,
al volver puede saber:
este paquete nunca terminó.
Entonces, en vez de dejarlo a medias,
revierte todo al estado anterior anotado.
Avanza un paso, luego toca el corte. En vez de dejarlo a medias, revierte por completo al inicio.
Cortado, y aun así el libro está intacto.
En vez de dejar una mitad desordenada
volvió limpiamente a antes del inicio.
Revertir todo se llama rollback.
Como el fallo no deja rastro,
basta con intentarlo de nuevo desde el inicio.
Gracias a eso, puedes confiar el trabajo tranquilo.
Pero cuando varias personas intentan cambiar
el mismo saldo a la vez, qué pasa entonces?
Aun llegando a la vez, se atiende por turno
Vimos algo así en el sistema operativo.
Cuando dos tocan el mismo recurso a la vez,
el resultado se enreda, una condición de carrera.
Un saldo es igual.
Dos personas leen el saldo a la vez
y cada una escribe su propio valor cambiado,
así el que escribe después sobrescribe el resultado del primero.
Un cambio entero simplemente desaparece.
Por eso hacemos que se atiendan uno por uno, por turno.
Envía dos personas a la vez. Sin control una sobrescribe y se enreda, pero por turno ambas se aplican.
Sin control, el cambio de un lado se esfumó.
Atendidos por turno, ambos se aplicaron bien.
Aun llegando a la vez, hacen fila un momento,
y al siguiente se le atiende solo tras terminar uno.
Con solo fijar un orden, el sobrescribir desaparece.
Sumado al empaquetado y al rollback de antes,
ahora escribir a la vez no se enreda.
Cuando estas tres se juntan, los datos se vuelven
fiables como para confiar y encomendar.
Resumamos
Reunido en una línea, es esto.
Junta en uno los cambios que deben ir en pares.
Todo ocurre, o nada ocurre.
Si algo falla a medias, en vez de dejar la mitad
revierte todo a antes del inicio. Eso es rollback.
Cuando varios intentan cambiar el mismo sitio a la vez,
los pone en fila por turno y bloquea el sobrescribir.
Todo o nada, rollback ante un tropiezo,
y sin enredos a la vez. Eso es una transacción.
Toca los puntos clave en orden para repasar. (transferencia es un par -> todo o nada -> rollback ante un tropiezo -> sin enredos a la vez)
Ahora conoces una promesa fiable
para cambiar datos a salvo.
El hueco de vértigo donde el dinero se esfumaba,
el accidente de la mitad que quedaba al cortarse la luz,
el caos de cambios simultáneos enredados,
todo se desenredó con una idea: un solo paquete.
Cuánto más comparten un sistema muchos,
más valiosa es esta promesa.
La próxima también, sigamos explorando juntos
la sabiduría de manejar datos.