Sincronización en Sistemas Distribuidos
SINCRONIZACIÓN
Se habla de sincronización cuando varios procesos se ejecutan a la vez con el propósito de completar una tarea y evitar así condiciones de carrera, que pudieran desembocar en un estado inesperado. También se habla de sincronización de datos cuando dos dispositivos se actualizan de forma que contengan los mismo datos.
SINCRONIZACIÓN DE RELOJES
Un sistema distribuido debe permitir el apropiado uso de los recursos, debe encargarsede un buen desempeño y de la consistencia de los datos, además de mantener seguras todas estas operaciones
La sincronización de procesos en los sistemas distribuidos resulta más compleja que en los centralizados, debido a que la información y el procesamiento se mantienen en diferentes nodos. Un sistema distribuido debe mantener vistas parciales y consistentes de todos los procesos cooperativos y de cómputo.
Tales vistas pueden ser provistas por los mecanismos de sincronización.
El término sincronización se define como la forma de forzar un orden parcial o total en cualquier conjunto de eventos, y es usado para hacer referencia a tres problemas distintos pero relacionados entre sí:
1.La sincronización entre el emisor y el receptor.
2.La especificación y control de la actividad común entre procesos cooperativos.
3.La serialización de accesos concurrentes a objetos compartidos por múltiples procesos.
Haciendo referencia a los métodos utilizados en un sistema centralizado, el cual hace uso de semáforos y monitores; en un sistema distribuido se utilizan algoritmos distribuidos para sincronizar el trabajo común entre los procesos y estos algoritmos.
RELOJES FÍSICOS
*Los valores de tiempo asignados a los eventos no tienen porqué ser cercanos alos tiempos reales en los que ocurren.
*En ciertos sistemas es importante la hora real del reloj:
*Se precisan relojes físicos externos (más de uno).
*Se deben sincronizar:
*Con los relojes del mundo real.
*Entre sí.
Desde antiguo el tiempo se ha medido astronómicamente.
Se considera el día solar al intervalo entre dos tránsitos consecutivos del sol, donde el tránsito del sol es el evento en que el sol alcanza su punto aparentemente más alto en el cielo.
El segundo solar se define como 1 / 86.400 de un día solar.
Como el período de rotación de la tierra no es constante, se considera el segundo solar promedio de un gran número de días.
Los físicos definieron al segundo como el tiempo que tarda el átomo de cesio 133 para hacer 9.192.631.770 transiciones:
•Se tomó este número para que el segundo atómico coincida con el segundo solar promedio de 1958. :
•Operan estaciones de radio de onda corta o satélites de comunicaciones.
•Transmiten pulsos UTC con cierta regularidad establecida (cada segundo, cada 0,5 mseg, etc.).
•Se deben conocer con precisión la posición relativa del emisor y del receptor:
o Se debe compensar el retraso de propagación de la señal.
o Si la señal se recibe por módem también se debe compensar por la ruta de la señal y la velocidad del módem.
o Se dificulta la obtención del tiempo con una precisión extremadamente alta.
•Se tomó este número para que el segundo atómico coincida con el segundo solar promedio de 1958. :
•Operan estaciones de radio de onda corta o satélites de comunicaciones.
•Transmiten pulsos UTC con cierta regularidad establecida (cada segundo, cada 0,5 mseg, etc.).
•Se deben conocer con precisión la posición relativa del emisor y del receptor:
o Se debe compensar el retraso de propagación de la señal.
o Si la señal se recibe por módem también se debe compensar por la ruta de la señal y la velocidad del módem.
o Se dificulta la obtención del tiempo con una precisión extremadamente alta.
ALGORITMOS PARA LA SINCRONIZACIÓN DE RELOJES
ALGORITMO DE LAMPORT
Lamport demostró que la sincronización de relojes es posible y presentó un algoritmo para lograrlo.
Lamport señaló que la sincronización de relojes no tiene que ser absoluta:
- Si 2 procesos no interactúan no es necesario que sus relojes estén sincronizados.
- Generalmente lo importante no es que los procesos estén de acuerdo en la hora, pero sí importa que coincidan en el orden en que ocurren los eventos.
- No interesa su cercanía particular al tiempo real (oficial).
- Los relojes se denominan relojes lógicos.
- Deben ser iguales (estar sincronizados).
- No deben desviarse del tiempo real más allá de cierta magnitud.
- Si “a” y “b” son eventos en el mismo proceso y “a” ocurre antes de “b”, entonces “a –> b” es verdadero.
- “Ocurre antes de” es una relación transitiva:
- Si “a –> b” y “b –> c”, entonces “a –> c”.
- Si dos eventos “x” e “y” están en procesos diferentes que no intercambian mensajes, entonces “x –> y” no es verdadero, pero tampoco lo es “y –> x”:
- Se dice que son eventos concurrentes.
- Se debe cumplir que:
- Si “a –> b” entonces “C(a) < C(b)”.
- El tiempo del reloj, “C”, siempre debe ir hacia adelante (creciente), y nunca hacia atrás (decreciente).
Consideramos tres procesos que se ejecutan en diferentes máquinas, cada una con su propio reloj y velocidad (ver Figura 9.1:
- El proceso “0” envía el mensaje “a” al proceso “1” cuando el reloj de “0” marca “6”.
- El proceso “1” recibe el mensaje “a” cuando su reloj marca “16”.
- Si el mensaje acarrea el tiempo de inicio “6”, el proceso “1” considerará que tardó 10 marcas de reloj en viajar.
- El mensaje “b” de “1” a “2” tarda 16 marcas de reloj.
- El mensaje “c” de “2” a “1” sale en “60” y llega en “56”, tardaría un tiempo negativo, lo cual es imposible.
- El mensaje “d” de “1” a “0” sale en “64” y llega en “54”.
- Lamport utiliza la relación “ocurre antes de”:
- Si “c” sale en “60” debe llegar en “61” o en un tiempo posterior.
- Cada mensaje acarrea el tiempo de envío, de acuerdo con el reloj del emisor.
- Cuando un mensaje llega y el reloj del receptor muestra un valor anterior al tiempo en que se envió el mensaje:
- El receptor adelanta su reloj para que tenga una unidad más que el tiempo de envío.
Este algoritmo cumple nuestras necesidades para el tiempo global, si se hace el siguiente agregado:
- Entre dos eventos cualesquiera, el reloj debe marcar al menos una vez.
- Dos eventos no deben ocurrir exactamente al mismo tiempo.
- Si “a” ocurre antes de “b” en el mismo proceso, “C(a) < C(b)”.
- Si “a” y “b” son el envío y recepción de un mensaje, “C(a) < C(b)”.
- Para todos los eventos “a” y “b”, “C(a)” es distinto de “C(b)”.
ALGORITMO DE CRISTIAN
Es adecuado para sistemas en los que:
- Una máquina tiene un receptor UTC, por lo que se la llama despachador del tiempo.
- El objetivo es sincronizar todas las máquinas con ella.
Cuando el emisor obtiene la respuesta puede hacer que su tiempo sea “CUTC”.
Un gran problema es que el tiempo no puede correr hacia atrás:
- “CUTC” no puede ser menor que el tiempo actual “C” del emisor.
- La atención del requerimiento en el servidor de tiempos requiere un tiempo del manejador de interrupciones.
- También se debe considerar el tiempo de transmisión.
- Si el cronómetro genera 100 interrupciones por segundo:
- Cada interrupción añade 10 mseg al tiempo.
- Para atrasar solo agregaría 9 mseg.
- Para adelantar agregaría 11 mseg.
- El tiempo inicial (envío) “T0”.
- El tiempo final (recepción) “T1”.
- Ambos tiempos se miden con el mismo reloj.
- El tiempo de propagación será (T1 - T0 - I) / 2.
- Se toman varias mediciones.
- Se descartan los valores extremos.
- Se promedia el resto.
ALGORITMO DE BERKELEY
En el algoritmo de Berkeley el servidor de tiempo:
- Es activo.
- Realiza un muestreo periódico de todas las máquinas para preguntarles el tiempo.
- Con las respuestas:
- Calcula un tiempo promedio.
- Indica a las demás máquinas que avancen su reloj o disminuyan la velocidad del mismo hasta lograr la disminución requerida.
ALGORITMOS CON PROMEDIOS
Los anteriores son algoritmos centralizados.
Una clase de algoritmos descentralizados divide el tiempo en intervalos de resincronización de longitud fija:
- El i -ésimo intervalo:
- Inicia en “T0 + i R” y va hasta “T0 + (i + 1) R”.
- “T0” es un momento ya acordado en el pasado.
- “R” es un parámetro del sistema.
Debido a la diferente velocidad de los relojes las transmisiones no serán simultáneas.
Luego de que una máquina transmite su hora, inicializa un cronómetro local para reunir las demás transmisiones que lleguen en cierto intervalo “S”.
Cuando recibe todas las transmisiones se ejecuta un algoritmo para calcular una nueva hora para los relojes.
Una variante es promediar los valores de todas las demás máquinas.
Otra variante es descartar los valores extremos antes de promediar (los “m” mayores y los “m” menores).
Una mejora al algoritmo considera la corrección por tiempos de propagación.
TEMA V
Procesos y Procesadores en Sistemas Distribuidos
PROCESOS Y PROCESADORES
Un proceso es un concepto manejado por el sistema operativo que consiste en el conjunto formado por: Las instrucciones de un programa destinadas a ser ejecutadas por el microprocesador. Su estado de ejecución en un momento dado, esto es, los valores de los registros de la CPU para dicho programa. Su memoria de trabajo, es decir, la memoria que ha reservado y sus contenidos.
Un microprocesador es un circuito electrónico integrado que actúa como unidad central de proceso de un ordenador, proporcionando el control de las operaciones de cálculo. Están formados por componentes extremadamente pequeños formados en una única pieza plana de poco espesor. Su componente principal son los semiconductores, principalmente silicio y germanio. Pueden llegar a tener varias decenas de millones transistores, además de otros componentes electrónicos como diodos, resistencias, condensadores todo ello en varios milímetros cuadrados.
HILOS Y MULTIHILOS
* Es una secuencia de código que se ejecuta dentro de un proceso.
* Procesos Ligeros (LWP)
* Hilos de instrucciones o hilos de control
* Comparte espacio de direcciones y otra información global con su proceso.
* Registros, pila, máscaras de señal y otros datos específicos de hilos son locales a cada hilo.
MODELOS DE SISTEMAS
* Los procesadores distribuidos se pueden organizar de varias formas:
* Modelo de estación de trabajo.
* Modelo de la pila de procesadores.
* Modelo híbrido.
MODELO DE ESTACIÓN DE TRABAJO
El sistema consta de estaciones de trabajo (PC) dispersas conectadas entre sí mediante una red de área local (LAN).
Pueden contar o no con disco rígido en cada una de ellas.
Los usuarios tienen:
- Una cantidad fija de poder de cómputo exclusiva.
- Un alto grado de autonomía para asignar los recursos de su estación de trabajo.
- Sin disco:
- Bajo costo, fácil mantenimiento del hardware y del software, simetría y flexibilidad.
- Gran uso de la red, los servidores de archivos se pueden convertir en cuellos de botella.
- Disco para paginación y archivos de tipo borrador:
- Reduce la carga de la red respecto del caso anterior.
- Alto costo debido al gran número de discos necesarios.
- Disco para paginación, archivos de tipo borrador y archivos binarios (ejecutables):
- Reduce aún más la carga sobre la red.
- Alto costo y complejidad adicional para actualizar los binarios.
- Disco para paginación, borrador, binarios y ocultamiento de archivos:
- Reduce aún más la carga de red y de los servidores de archivos.
- Alto costo.
- Problemas de consistencia del caché.
- Sistema local de archivos completo:
- Escasa carga en la red.
- Elimina la necesidad de los servidores de archivos.
- Pérdida de transparencia.
MODELO DE PILA DE PROCESADORES
Se dispone de un conjunto de cpu que se pueden asignar dinámicamente a los usuarios según la demanda.
Los usuarios no disponen de estaciones de trabajo sino de terminales gráficas de alto rendimiento.
No existe el concepto de propiedad de los procesadores, los que pertenecen a todos y se utilizan compartidamente.
El principal argumento para la centralización del poder de cómputo como una pila de procesadores proviene de la teoría de colas:
- Llamamos “l” a la tasa de entradas totales de solicitudes por segundo de todos los usuarios combinados.
- Llamamos “m” a la tasa de procesamiento de solicitudes por parte del servidor.
- Para una operación estable debe darse que “m > l”:
- Se pueden permitir pequeños lapsos de tiempo en los que la tasa de entrada exceda a la de servicio.
- Llamamos “T” al promedio de tiempo entre la emisión de una solicitud y la obtención de una respuesta completa:
- T = 1 / ( m - l ).
- Cuando “ l ” tiende a “0”, “T” no tiende a “0”.
- Supongamos que tenemos “n” multiprocesadores personales, cada uno con cierto número de cpu y con su propio sistema de colas con tasas “ l ” y “ m ” y tiempo “T”:
- Si reunimos todas las cpu y formamos una sola pila de procesadores tendremos un solo sistema de colas en vez de “n” colas ejecutándose en paralelo.
- La tasa de entrada será “n l”, la tasa de servicio será “n m” y el tiempo promedio de respuesta será:
- T1 = 1 / (n m - n l) = 1 / n ( m - l) = T / n.
- Conclusión: si reemplazamos “n” pequeños recursos por uno grande que sea “n” veces más poderoso:
- Podemos reducir el tiempo promedio de respuesta “n” veces.
En este modelo los procesadores se asignan dinámicamente a los usuarios según la demanda. A los usuarios se les dan terminales gráficas de alto rendimiento, ya que la mayoría de usuarios buscan una interfaz gráfica de calidad eficiente. Estos procesadores se utilizan compartidamente entre todos los usuarios, los cuales pueden obtener datos de la CPU durante periodos cortos, y luego regresan a la pila para ser utilizados por otros usuarios.
MODELO HÍBRIDO
Se puede establecer una mediación al proporcionar a cada usuario una estación de trabajo personal y además tener una pila de procesadores. Aunque esta solución es más cara que cualquiera de los dos modelos puros, combina las ventajas de arribos. El trabajo interactivo se puede llevar a cabo en las estaciones de trabajo, con una respuesta garantizada. Sin embargo, las estaciones inactivas no se utilizan, lo cual hace más sencillo el diseño del sistema. Sólo se dejan sin utilizar. En vez de esto, todos los no interactivos se ejecutan en la pila de procesadores, así como todo el cómputo pesado en general. Este modelo proporciona una respuesta interactiva más rápida, un uso eficiente de los recursos y un diseño sencillo.
TEMA VI
Asignacion de Procesadores
MODELOS DE ASIGNACIÓN
Los algoritmos de asignación intentan optimizar algo:
Uso de las cpu:
Maximizar el número de ciclos de cpu que se ejecutan para trabajos de los usuarios.
Minimizar el tiempo de inactividad de las cpu.
Tiempo promedio de respuesta:
Minimizar no los tiempos individuales de respuesta sino los tiempos promedio de respuesta.
Tasa de respuesta:
Minimizar la tasa de respuesta, que es el tiempo necesario para ejecutar un proceso en cierta máquina dividido por el tiempo que tardaría en cierto procesador de referencia.
Por lo general, cada procesador hace su planificación local (si tiene varios procesos en ejecución), sin preocuparse por lo que hacen los demás procesadores.
La dificultad básica se puede mostrar mediante un ejemplo, en el cual los procesos A y B se ejecutan en un procesador y los procesos C y D en otro.
Lo que se necesita es una forma de garantizar que los procesos con comunicación frecuente se ejecuten de manera simultánea.
PLANIFICACIÓN EN SISTEMAS DISTRIBUIDOS
Por lo general, cada procesador hace su planificación local (si tiene varios procesos en ejecución), sin preocuparse por lo que hacen los demás procesadores. Lo normal es que este método funcione. Sin embargo, si un grupo de procesos relacionados entre sí y con gran interacción se ejecutan en distintos procesadores, la planificación independiente no es el camino más eficiente.
La dificultad básica se puede mostrar mediante un ejemplo, en el cual los procesos A y B se ejecutan en un procesador y los procesos C y D en otro. El tiempo de cada procesador se comparte en pedazos de 100 milisegundos, donde A y C se ejecutan en los pedazos pares y B y D en los nones, como se muestra en la figura 4-20(a).
Supongamos que A envía muchos mensajes o lleva a cabo muchas llamadas a procedimientos remotos de D. Durante el tiempo 0, A inicia y llama de inmediato a D, que por desgracia no se ejecuta en ese momento, puesto que es el turno de C. Después de 100 milisegundos, se alternan los procesos, D obtiene el mensaje de A, lleva a cabo el trabajo y responde con rapidez. Puesto que B está ejecutándose, pasarán otros 100 milisegundos antes de que A obtenga la respuesta y pueda proseguir. El resultado neto es un intercambio de mensajes cada 200 milisegundos.
Lo que se necesita es una forma de garantizar que los procesos con comunicación frecuente se ejecuten de manera simultánea.
Aunque es difícil determinar en forma dinámica los patrones de común entre los procesos, en muchos casos, un grupo de procesos relacionados entre sí iniciarán juntos.
TOLERANCIA A FALLAS
La promesa de los sistemas distribuidos sólo se puede cumplir cuando a la base hardware adecuada se le añaden políticas y mecanismos tolerantes a fallas. El objetivo del diseño y construcción de sistemas tolerantes a fallas consiste en garantizar que el sistema continúe funcionando de manera correcta como un todo, incluso en presencia de fallas.
Se dice que un sistema falla cuando no cumple su especificación. En algunos casos, como en un sistema de ordenamiento distribuido de productos en un supermercado, una falla podría provocar la falta de algunos productos en la tienda. En otros casos, como en un sistema distribuido para el control de tráfico aéreo, una falla podría ser catastrófica. Como las computadoras y los sistemas distribuidos se utilizan cada vez más en misiones donde la seguridad es crítica, la necesidad de soportar las fallas cada vez es mayor.
Un sistema consiste de un conjunto de componentes de hardware y software y son diseñados para proveer un servicio específico. Los componentes de un sistema pueden estar interrelacionados entre ellos. Un desperfecto de un sistema ocurre cuando el sistema no desempeña estos servicios de la manera especificada. Un estado erróneo en un sistema es un estado en el cual podría conducir a un fallo en el sistema. Un fallo es una condición física anormal, las causas de un fallo incluyen: errores de diseño (como errores en la especificación del sistema o en la implementación), problemas de fabricación, deterioro por el uso u otros problemas externos (como condiciones ambientales adversas, interferencia electromagnética, entradas imprevistas o el mal uso del sistema). Un error es una parte del estado del sistema la cual difiere de los valores esperados.
Un error del sistema puede ser visto como una manifestación de mal funcionamiento del sistema, el cual podría conducir a un fallo del sistema. Es necesario entonces, que el sistema sea capaz de recuperarse de las fallas, necesitamos deshacernos del estado de error del sistema, en otras palabras, la recuperación de un fallo, es un proceso que involucra la restauración de un estado erróneo a un estado libre de error.
TRANSACCIONES
Una transacción es una colección de acciones que hacen transformaciones consistentes de los estados de un sistema preservando la consistencia del sistema. Una base de datos está en un estado consistente si obedece todas las restricciones de integridad definidas sobre ella. Los cambios de estado ocurren debido a actualizaciones, inserciones, y supresiones de información. Por supuesto, se quiere asegurar que la base de datos nunca entra en un estado de inconsistencia. Sin embargo, durante la ejecución de una transacción, la base de datos puede estar temporalmente en un estado inconsistente. El punto importante aquí es asegurar que la base de datos regresa a un estado consistente al fin de la ejecución de una transacción
Lo que se persigue con el manejo de transacciones es por un lado tener una transparencia adecuada de las acciones concurrentes a una base de datos y por otro lado tener una transparencia adecuada en el manejo de las fallas que se pueden presentar en una base de datos.
IMPORTANCIA EN LA COMUNIDAD DISTRIBUIDA
Una transacción es generalmente una unidad de trabajo que se hace a nombre de una aplicación o componente. Cada transacción puede estar compuesta de múltiples operaciones realizadas en datos que están dispersos en uno o varios procesos o en una o varias máquinas. Cada transacción asegura el trabajo de proteger la integridad del estado de un sistema al proveer cuatro garantías básicas conocidas como las propiedades ACID: atomicidad (atomicity), consistencia (consistency), aislamiento (isolation) y durabilidad (durability) y que se explican a continuación.
Una transacción tiene que ser atómica lo que significa que es indivisible; todas las operaciones deben ejecutarse o ninguna en lo absoluto. No debe haber posibilidad de que solo una parte se ejecute. En un sistema bancario, por ejemplo, una transferencia de dinero entre dos cuentas de cheques tiene que ser atómica; tomar dinero de una cuenta para agregarlo a otra. No es posible ejecutar una de las operaciones y la otra no. La atomicidad se garantiza a través de mecanismos de base de datos con los que se hace el seguimiento de la transacción. Si la transacción falla por cualquier razón, las actualizaciones que se hayan realizado hasta el momento serán deshechas. Solo si la transacción llega al fin los cambios se volverán parte de la base de datos. La propiedad de atomicidad permite escribir operaciones que emulan transacciones de negocio tales como retiros de cuentas de cheques, reservaciones de vuelo o compra y venta de bonos entre otras. Cada una de estas acciones, requiere actualizar varios datos y al implementarlas acciones en una transacción, se asegura que todas o ninguna de las actualizaciones se realizan. Aún más, la atomicidad garantiza que la base de datos se queda en un estado conocido después de la falla de una transacción lo que reduce el requerimiento de intervención manual. La terminación exitosa de una transacción se conoce como commit mientras que a la falla de una transacción se le conoce como abort.
Consistencia (Consistency). Una transacción mantendrá la consistencia de la base de datos. Esto es, si la base de datos se encuentra en un estado consistente antes de ejecutar la transacción, una vez que ésta termine la consistencia de la base de datos deberá conservarse. Por consistente se debe entender, internamente consistente. En términos de base de datos esto significa que se satisfacen todas las restricciones en cuanto a su integridad que incluyen:
Todos los valores de la llave primaria son únicos.
La base de datos mantiene integridad referencial lo que significa que los registros solo referencian información que existe.
Ciertos predicados se mantienen. Por ejemplo, la suma de los gastos es menor o igual al presupuesto.
A diferencia de la atomicidad, el aislamiento y la durabilidad, la consistencia es una práctica de programación. La atomicidad, el aislamiento y la durabilidad están aseguradas estén o no programadas para preservar la consistencia. Es responsabilidad del desarrollador de la aplicación asegurar que su programa preserva la consistencia.
Aislamiento (Isolation). La tercera propiedad de una transacción es el aislamiento. Se dice que un conjunto de transacciones está aislado si el efecto del sistema que las ejecuta es el mismo que si ejecutara cada una a la vez; las transacciones se ejecutan en secuencia. Tómese, por ejemplo, el caso de un sistema bancario en el que dos transacciones intentaran hacer un retiro de los últimos $200 de una cuenta de cheques. Si se permite que al mismo tiempo, dos transacciones consulten el saldo antes de afectarlo, ambas determinarán que hay fondos suficientes y realizarán el retiro. En cambio, si las transacciones se ejecutan en serie -una detrás de otra-, solo una de las transacciones será capaz de retirar los últimos $200. La siguiente encontrará el saldo de la cuenta en cero. El usuario final tiene la percepción de que su transacción es la única en el sistema. La base de datos típicamente usa técnicas de locking o versioning en los datos que cada transacción accede. El efecto de esto es hacer que la ejecución parezca en serie aunque, internamente, el sistema ejecuta las transacciones en paralelo. Por la importancia y el impacto que tiene el aislamiento (isolation) en la escalabilidad, se le ha dedicado un capítulo completo de este libro.
Durabilidad (Durability). Cuando una transacción termina de ejecutarse, todas sus actualizaciones se graban en algún tipo de medio de almacenamiento, típicamente disco, en donde se asegura que las actualizaciones no se perderán. Aun si el sistema operativo falla, los resultados de la transacción son almacenados en disco y podrán ser encontrados ahí cuando se recupere el sistema operativo. Más aún, la durabilidad a menudo debe mantenerse por un periodo largo. Por ejemplo, por cuestiones de auditoria La durabilidad se obtiene por medio de un mecanismo que guarda en una bitácora (log) copia de todas las actualizaciones que una transacción realiza. Cuando se ejecuta el commit de la transacción, el sistema se asegura que todos los registros escritos en el log están en disco y entonces informa a la transacción que los resultados son durables. Si después del commit de la transacción y antes de escribirse a la base de datos, el sistema falla, es responsabilidad de éste reparar la base de datos lo que logra por medio de una lectura del log para verificar que se efectuó cada modificación hecha por una transacción committed. De no cumplirse esta condición, entonces vuelve a realizar las actualizaciones. Cuando esta actividad de recuperación se ha terminado, el sistema reanuda su operación normal. Cualquier nueva transacción encontrará un estado en la base de datos que incluye todas las actualizaciones. En resumen, las transacciones garantizan que los cambios al estado de un sistema se aplican atómicamente, dejan al sistema consistente, están aisladas una de otra mientras están en progreso y serán durables aun en casos de una falla catastrófica.
