Transacciones: escribir a la vez sin enredos
Imagina que envias 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 recibio nada. Para evitar esos accidentes, tratar varios cambios como un solo paquete es una transaccion.
Una transferencia es una resta y una suma, un par
Antes aprendimos que una base de datos
es un almacen 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 esta bien.
La suma total del dinero ha cambiado.
Ese corto hueco entre la resta y la suma,
justo ahi esta 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 transaccion.
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.
Asi nunca queda nada a medias.
Todo ocurre, o nada ocurre.
El estado intermedio no se le muestra a nadie.
Ejecutala como un paquete. Se confirma solo cuando ambos cambios estan listos, y cancelar quita los dos.
Ambos se confirman juntos, asi 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 desaparecio.
Manejado asi, todo o nada,
el libro jamas puede descuadrarse.
Pero que 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.
Asi, aunque la luz muera a medias,
al volver puede saber:
este paquete nunca termino.
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 asi el libro esta intacto.
En vez de dejar una mitad desordenada
volvio 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, que pasa entonces?
Aun llegando a la vez, se atiende por turno
Vimos algo asi en el sistema operativo.
Cuando dos tocan el mismo recurso a la vez,
el resultado se enreda, una condicion de carrera.
Un saldo es igual.
Dos personas leen el saldo a la vez
y cada una escribe su propio valor cambiado,
asi el que escribe despues sobrescribe el resultado del primero.
Un cambio entero simplemente desaparece.
Por eso hacemos que se atiendan uno por uno, por turno.
Envia 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 esfumo.
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 linea, 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 transaccion.
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 vertigo donde el dinero se esfumaba,
el accidente de la mitad que quedaba al cortarse la luz,
el caos de cambios simultaneos enredados,
todo se desenredo con una idea: un solo paquete.
Cuanto mas comparten un sistema muchos,
mas valiosa es esta promesa.
La proxima tambien, sigamos explorando juntos
la sabiduria de manejar datos.