TRANSACCIONES DISTRIBUIDAS

TRANSACCIONES DISTRIBUIDAS
Sistemas de operación II Abril-Julio 2018 Yudith Cardinale

INDICE Introducción y definiciones Algoritmos de compromiso
Two Phase Commit Algoritmos de control de concurrencia Locks, Optimista, Timestamps Recuperación de transacciones Listas de intención Versiones sombras Tratamientos de interbloqueos

INTRODUCCIÓN Y DEFINICIONES
Transacciones Unidad de cálculo consistente, confiable y atómica A B C Operaciones conflictivas A B C Delay Ejecución Operaciones compuestas Serialización de operaciones conflictivas

Una transacción aplica a datos recuperables, puede estar formada por operaciones simples o compuestas y su intención es que sea atómica. Hay dos aspectos que se deben cumplir para lograr la atomicidad: 1. Todo-o-nada: si una transacción termina exitosamente, los efectos de todas sus operaciones son registrados en los ítems de datos. Si falla no tiene ningún efecto.

La propiedad todo-o-nada también considera: Atomicidad ante fallas: los efectos son atómicos aún cuando el servidor falla. Durabilidad: después que una transacción ha terminado exitosamente, todos sus efectos son salvados en almacenamiento permanente. 2. Aislamiento: cada transacción debe ser ejecutada sin interferencias de otras transacciones, es decir, los resultados intermedios de una transacción no deben ser visibles a otras transacciones. Estas propiedades tambien son conocidas como propiedades ACID

Propiedades ACID A: Atomicidad (atomicity) - propiedad todo-o-nada.
Para soportar la atomicidad ante fallas y la durabilidad, los ítemes de datos deben ser recuperables. Hay dos tipos de fallas: Transacción falla por si misma por errores en los datos de entrada, deadlocks, etc. Recuperación de la transacción. Fallas por caidas del sistema, de los medios de E/S, de los procesadores, de las líneas de comunicación, fallas de energía, etc. Recuperación de caidas.

Propiedades ACID A: Atomicidad (atomicity) - propiedad todo-o-nada.
En la recuperacion de caidas: El sistema es quién tiene la responsabilidad de decidir qué hacer ante la recuperación de una falla: Terminar de ejecutar el resto de las acciones. Deshacer las acciones que se había realizado. Para proveer la recuperación se usan técnicas de almacenamiento estable.

Propiedades ACID C: Consistencia (consistency) - una transacción toma el sistema en un estado consistente y lo deja en un estado consistente. Sistema consistente- Tj-stma puede estar inconsistente - Tj - Sistema consistente se inicia finaliza I: Aislamiento (Isolation): implica seriabilidad de las transacciones. Se les permite a las transacciones ejecutarse concurrentemente si se obtiene el mismo efecto de una ejecución secuencial (serialmente equivalentes). D: Durabilidad (durability).

Primitivas sobre transacciones
begin_transaction tid : inicia una transacción y devuelve un identificador de la transacción close_transaction(tid) (Commit, Abort) Commit: la transacción termina exitosamente y sus efectos van a almacenamiento permanente. Abort: no se reflejan los cambios. Los abortos pueden ser causados por la propia naturaleza de la transacción, por conflictos con otras transacciones o por fallas. abort_transaction(tid): aborto intencional. read y write: típicamente una transacción se compone de una serie de lecturas y escrituras y algunos cálculos.

Transacciones anidadas
Las transacciones pueden contener subtransacciones. Problema: Si una transacción interna realiza commit y una más externa abort, se pierden las propiedades de atomicidad y aislamiento por cumplir con la durabilidad. Generalmente la durabilidad sólo se considera para la transacción más externa. En algunaos sistemas, la transacción superior puede decidir hacer commit aún cuando alguna subtransacción aborta.

Implementación de las transacciones
Espacio de trabajo privado: Se copian los datos en un espacio propio de cada transacción Al finalizar exitosamente la transacción, se actualiza la base de datos Lista de intención (writeahead log) Las actualizaciones son realizadas directamente en la base de datos Se lleva un registro de los cambios realizados

Transacciones Distribuidas
Sus actividades envuelven múltiples servidores. Los ítemes de datos de un servidor pueden estar distribuidos entre varios servidores y, en general, una transacción de un cliente puede envolver múltiples servidores. Las transacciones distribuidas pueden ser simples o anidadas. Cliente: begin_transaction call X.x call Y.y call Z.z end_transaction X Y cliente Z

M T11 X T1 T N T12 T21 Cliente Y T2 P T22 Transascción distribuida anidada

Cuando una transacción distribuida termina, la propiedad de atomicidad exige que todos los servidores acuerden lo mismo (commit) o todos aborten (abort). Existen protocolos para llegar a compromisos (Two-Phase-Commit y Three- Phase_Commit) Las transacciones distribuidas deben ser globalmente serializadas. Existen protocolos de control de concurrencia distribuida.

Procesamiento de transacciones distribuidas
TPS TPS Transaction Manager Transaction Manager TPS: Transaction Processing System scheduler scheduler comunicación Data Manager Data Manager Recovery Manager Recovery Manager Cache Manager Cache Manager

Un cliente inicia una transacción (begin_transaction) sobre un TPS. El Transaction Manager identifica y localiza los objetos invocados por la transacción. Las invocaciones a los objetos locales son pasados al Scheduler local, las invocaciones a objetos remotos son pasados a TPS remotos correspondientes. Observaciones: Un cliente inicia una transacción (begin_transaction) en un único nodo ==> Nodo coordinador. Un objeto reside en único nodo (no hay replicación de objetos). La invocación de tal objeto toma lugar en ese nodo.

Observaciones (cont.): Existen mecanismos para localizar un objeto, dado su identificador único. Las instancias de TPS deben cooperar Coordinador de una transacción distribuida Un cliente comienza una transacción enviando un begin_transaction a cualquier servidor TPS. Éste se convierte en el coordinador y los que se tengan que contactar a partir de aquí se convierten en trabajadores.

Coordinador de una transacción distribuida (cont.) Para esto se requieren otras primitivas: AddServer (tid, server_id del coordinador): Es enviado por el coordinador a otro servidor informándole que está envuelto en la transacción tid. NewServer(tid, server_id del trabajador): Es la respuesta ante un AddServer de un trbajador al coordinador. El coordinador lo registra en su lista de trabajadores.

Algoritmos de compromiso
Cuando el coordinador recibe un requerimiento Commit de una transación, tiene que asegurar: Atomicidad: Todos los nodos se comprometen con los cambios o ninguno lo hace y cualquier otra transacción percibe los cambios en todos los nodos o en ninguno. Aislamiento:Los efectos de la transacción no son visibles hasta que todos los nodos hayan tomado la decisión irrevocable commit o abort.

El protocolo Two-Phase Commit (TPC): Durante el progreso de una transacción no hay comunicación entre el coordinador y los trabajadores, solo con AddServer y NewServer. El requerimiento commit o abort del cliente, llega al coordinador. Si es abort, el coordinador se lo informa inmediatamente a todos los trabajadores. Si es commit, se aplica el protocolo TPC.

coordinador trabajadores prepare no vote-abort yes wait vote-commit
inicial inicial prepare Fase 1: votación write begin_commit in log write abort in log no vote-abort ready? unilatreal abort yes wait vote-commit write ready in log global-abort yes write abort in log ready any no? global-commit Fase 2: acuerdo no write abort in log abort type msg? write commit in log ack commit abort write commit in log commit ack write end_transac in log abort commit

¿Cuáles serán las acciones del protocolo TPC ante timeouts? Timers en los estados del coordinador: Wait, Commit o Abort. Timeout en el estado Wait: Decide abortar la transacción, lo escribe en el log y envía el mensaje global_abort a los trabajadores. Timeout en los estados commit o abort: Envía el mensaje global_commit o global_abort respectivamente a los trabajadores que aún no han respondido y espera por sus ack. Timers en los estados de los trabajadores: Inicial o Ready. Timeout en el estado Inicial: Decide abortar unilatealmente. Si el mensaje prepare llega después, el trabajador puede enviar un vote_abort o ignorarlo. Timeout en el estado Ready: Se debe quedar bloqueado esperando alguna noticia

Paradigmas de comunicación para el TPC
TPC centralizado prepare vote global_C/A C/A TPC lineal prepare vc/va vc/va vc/va gc/ga gc/ga gc/ga gc/ga Menos mensajes, pero poco paralelismo C Fase 1 1 2 3 4 N Fase 2

Paradigmas de comunicación para el TPC
TPC distribuido prepare vc/va GC/GA El GC/GA es una decisión de cada participante de acuerdo a los votos recibidos Se elimina la fase 2 Lineal y distribuidos requieren conocer los Ids de todos los participantes.

Control de Concurrencia
La idea es resolver las operaciones conflictivas Operaciones conflictivas: 2 operaciones son conflictivas cuando sus efectos combinados dependen del orden en el cual fueron ejecutadas. Para dos transacciones A y B, se consideran conflictivas las siguientes operaciones: A B read read no conflictivas read write conflictivas write write conflictivas Cuando dos o más transacciones son conflictivas es necesario su serialización para asegurar la consistencia de los datos después de su ejecución.

Las operaciones conflictivas derivan en dos problemas: Actualizaciones perdidas Transacción T Transacción U balance=b.getBalance() balance=b.getBalance() b.setBalance(balance*1.1) b.setBalance(balance*1.1) Recuperaciones inconsistentes Transacción V Transacción W a.retirar(100) unasucursal.totalSucursal(a,b) b.deposita(100)) Según la ejecución el total es 300$ y debió ser 400$ Ambos problemas se resuelven definiendo Equivalencia Secuencial ==> Control de concurrencia Ejecución T U balance=200$ balance=220$ (balance debió ser ) Ejecución; a=200$ , b=200$ V W a=200$-100$ lee a=100$ lee b=200$ b=200$+100$ total=300$

Las transacciones pueden abortar, ante esta situación surgen otros problemas: lecturas sucias y escrituras prematuras Lecturas Sucias Transacción T Transacción U a.getBalance() (100$) a.depositar(10) (110$) a.getBalance() (110$) a.deposita(20) (130$) commit aborta U tomó el valor 110$ que ahora no es válido. - La estrategia para la recuperación es retrasar la acción de commit de U hasta que T finalice - Esto conlleva a la posibilidad de Abortos en Cascada (si T aborta, U debe abortar también)

Escrituras prematuras (perdida de actualizaciones) - La estrategia para la recuperación es retrasar los writes hasta el momento del commit Para evitar ambos problemas se debe proveer ejecución estricta de las transacciones (propiedad de aislamiento)

Algoritmo de locking o bloqueo
Nivel de granularidad del bloqueo: tiene que ver con el tamaño del objeto o dato que se está bloqueando A mayor granularidad (mayor fineza del grano), más pequeño es el tamaño del objeto. El nivel de granularidad es directamente proporcional al grado de paralelismo/concurrencia, pero también es directamente proporcional al grado de complejidad de los sistemas (mayor probabilidad de inter bloqueo). Mientras más fino el grano, mejor será el grado de paralelismo/concurrencia, pero mayor será la complejidad del sistema. El bloqueo puede ser a nivel de item, página, archivo, base de datos (donde item representa el grano más fino y base de datos corresponde al grano más grueso)

Consiste en que cada vez que un proceso necesita leer o escribir en un objeto como parte de una transacción, el objeto se bloquea hasta que la transacción culmine exitosamente (commit) y cualquier otra transacción que desee hacer alguna operación sobre dicho objeto tendrá que esperar hasta que sea desbloqueado. Los locks son adquiridos y liberados por el administrador de transacciones, esto implica que todo lo concerniente al control de concurrencia es transparente para el programador. El administrador de locks puede ser centralizado o local para cada máquina

lock otorgado lock solicitado Ninguno read OK write OK read read OK write Espera write read Espera - write Espera Una mejora: promoción de locks, si varias transacciones necesitan un objeto para lectura y luego para escritura, se les puede otorgar un lock de lectura hasta que alguna necesite escribir en el objeto. Se le otorgará el lock de escritura después de que todas las demás transacciones que tengan locks de lectura sobre el mismo objeto, lo liberen. La ventaja de esta mejora es que provee un mayor grado de paralelismo.

Resuelve “recuperaciones inconsistentes” No hay posibilidad de que dos operaciones conflictivas se ejecuten concurrentemente Resuelve “pérdida de actualizaciones” Si dos transacciones leen el mismo dato y luego lo modifican, la 2da. espera (ya sea por promoción o por no otorgamiento) El problema del algoritmo de locking es que puede ocasionar deadlocks y abortos en cascada y no asegura serialización, por lo que se han propuesto algunas variaciones para evitar tales problemas.

Two Phase Locking: “obtención” y “liberación” Durante la fase de “obtención”, la transacción trata de obtener todos los locks que necesite. Si no es posible obtener alguno, entonces espera. La segunda fase comienza cuando la transacción libera alguno de los locks, a partir de ese momento no podrá solicitar ningún otro lock (si lo hace, será abortada). La mejora: asegura serialización Desventaja: posibilidad de abortos en cascada y deadlocks.

Strict Two Phase Locking: La fase de “liberación” se realiza sólo cuando la transacción hace commit La mejora: asegura serialización y evita los abortos en cascada Desventajas: El nivel de paralelismo se degrada Permanece la posibilidad de deadlock Representa un alto costo de mantenimiento

Two Phase Locking Strict Two Phase Locking number of locks Fase de crecimiento Fase de liberación number of locks Fase de crecimiento Fase de liberación Se liberan todos los locks Time Time

Conservative Two Phase Locking: Las transacciones obtienen todos los locks necesarios antes de comenzar. La mejora: evita deadlocks y abortos en cascada Desventaja: nivel de paralelismo se degrada, posibilidad de inanición.

Algoritmo Optimista Se basa en las siguientes premisas:
“Los conflictos suceden poco” “Como vaya viniendo vamos viendo” “¡Adelante!, haz lo que quieras sin atender lo que los otros hacen, no te preocupes por los problemas ahora, preocúpate más tarde” Las modificaciones/accesos se hacen sobre espacios privados y se lleva registro de los datos que han sido modificados/accedidos. Al momento del commit, se chequea que los espacios privados sean válidos, de no serlos, se aborta la transacción. A toda transacción se le asigna un identificador (orden secuencial ascendente) para llevar una sucesión de transacciones en el tiempo.

Algoritmo Optimista Cada transacción cumple tres fases:
Trabajo:Todos los reads se ejecutan inmediatamente sobre la última versión “comprometida” del dato. Los writes crean versiones tentativas. Se mantiene un conjunto de lectura (datos leídos) y un conjunto de escritura (versiones tentativas de los datos). No hay posibilidad de “lecturas sucias”, ¿por qué? Validación: Ante la solicitud de un commit, se valida si la transacción realizó operaciones conflictivas con otras transacciones. Escritura: Si la transacción es validada, todos los cambios hechos sobre los espacios privados son actualizados en las versiones originales.

Algoritmo Optimista Fase de validación:
Ante el close_transaction, a cada transacción se le asigna un número (secuencial ascendente, i) que define su posición en el tiempo. La validación se basa en las siguientes reglas: Ti Tj Regla read write Ti no debe leer datos escritos por Tj (regla 1) write read Tj no debe leer datos escritos por Ti (regla 2) write write Ti no debe escribir datos escritos por Tj y Tj no debe escribir datos escritos por Ti (regla 3) Simplificación: fases de validación y escritura son secciones críticas, entonces se satisface la regla 3. Sólo hay que validar las reglas 1 y 2

Algoritmo Optimista Validación hacia atrás:
Los reads de las Tj se realizaron antes que la validación de Ti, entonces se cumple la regla 2. Sólo se valida la regla 1 para cada Tj: valid= true; for (Tj=startTn+1;Tj<=finishTn,Tj++) { if (“read_set” of Ti intersects “write_set” Tj) valid=false; } startTn: Tj más grande asignado a una transacción committed al momento que Ti entra a su fase de trabajo finishTn: Tj más grande asignado al momento que Ti entra a su fase de validación

Algoritmo Optimista Validación hacia atrás:
Sólo es necesario validar los conjuntos de lectura. Las transacciones que sólo hacen escritura no se validan. Si Ti no es válida, se aborta Transacciones anteriores committed T1 T2 T3 Transacción en validación Ti activa1 activa2 Validación Sólo se validan T2 y T3 T1 terminó antes que Ti comenzara Trabajo Escritura

Algoritmo Optimista Validación hacia delante:
Se satisface la regla 1 porque las transacciones activas no escriben mientras que Ti no se ha completado. Sólo se valida la regla 2 para cada Tid: valid= true; for (Tid=activa1;Tid<=activaN,Tid++) { if (“write_set” of Ti intersects “read_set” Tid) valid=false; } activaX: Representan transacciones que aún no han entrado a la fase de validación Las transacciones que sólo hacen lecturas no requieren ser validadas

Algoritmo Optimista Validación hacia adelante: Si Ti no es válida:
Aplazar la validación (¿le irá mejor en el futuro?) Abortar las activas y consumar Ti Abortar Ti (¿qué pasa si alguna de las futuras Tj es abortada? Transacciones anteriores committed T1 T2 T3 Transacción en validación Ti activa1 activa2 Validación Trabajo Escritura

Algoritmo Optimista Desventajas:
Hay posibilidad de inanición: una transacción puede abortar indefinidas veces y no se contempla mecanismo para evitar esto. También es importante saber que este algoritmo no serviría para nada en sistema con carga alta. Otra desventaja es que este algoritmo produce mucha sobrecarga porque hay que mantener los conjuntos de escritura de transacciones que ya terminaron (hacia atrás)

Algoritmo por Marcas de Tiempo
Las operaciones se validan al momento de ser ejecutadas Cuando una transacción comienza, se le asigna un timestamp Se trabaja con versiones tentativas Cada item de dato tiene asociado: Un timestamp de escritura (Twrite_commit), un timestamp de lectura (Tread) y un conjunto de versiones tentativas con su propio timestamp Un write aceptado genera una versión tentativa Un read se dirige a la versión con el máximo timestamp menor que el timestamp de la transacción

La validación se basa en las siguientes reglas: Regla Tj Ti Condición write read Tj no debe escribir un dato leído por Ti>Tj (requiere que Tj >= max(Tread) del dato) write write Tj no debe escribir un dato escrito por Ti>Tj (requiere que Tj > max(Twrite_commit) del dato) read write Tj no debe leer un dato escrito por Ti>Tj (requiere que Tj > Twrite_commit)

Para saber cuando un write es válido, se aplica el siguiente algoritmo (validación de las reglas 1 y 2- regla de escritura): Sea Tj una transacción que desea hacer un write sobre el objeto D. If ((Tj >= Max (Tread en D)) && (Tj > write_commit en D)) Proceder con el write sobre una versión tentativa nueva; else // write is too late Abortar Tj;

Regla de escritura a) T3->write b) T3-> write c) T3->write d) T3-> write T2 antes antes Versión committ después T3 después T2 T3 Versión tentativa T4 antes antes T3 Aborta después T3 T4 después

Validación de la regla 3 (regla de lectura): Tj hace read(D) if (Tj > Twrite_commit en D) { Dselected with Max (Twrite <=Tj en D); if (esCommit (Dselected)) { Procede el read sobre Dselected; } else { Esperar hasta que la Ti que hizo la versión tentativa de Dselected haga commit o abort; volver a comenzar; Abortar Tj; }

Regla de lectura a) T3->read b) T3-> read c) T3->read d) T3-> read read se ejecuta inmediatamente T4 read se ejecuta inmediatamente Versión committ Seleccionado Seleccionado Versión tentativa T2 read espera T3 Aborta Seleccionado

Recuperación de Transacciones
Se refiere a asegurar la atomicidad de las transacciones aún en presencia de fallas del servidor. La propiedad de atomicidad de las transacciones se expresa en dos aspectos: durabilidad y atomicidad en las fallas: La durabilidad requiere que los ítemes de datos sean salvados en almacenamiento permanente y disponibles indefinidamente. La atomicidad en las fallas requiere que los efectos de las transacciones sean atómicos aún cuando el servidor falle.

Recuperación de Transacciones
Cuando un servidor se está ejecutando mantiene sus ítemes de datos en memoria volátil y registra los comprometidos (committed) en archivos de recuperación. Así, la recuperación consiste en restaurar al servidor con las últimas versiones comprometidas de sus ítemes de datos, a partir del almacenamiento permanente. Los requerimientos de durabilidad y atomicidad en las fallas no son independientes y se tratan con el mismo mecanismo : El Administrador de Recuperación (AR).

Funciones del Administrador de Recuperación
Salvar los ítems de datos en almacenamiento permanente, en un archivo de recuperación, de las transacciones comprometidas. Restaurar los ítemes de datos del servidor después de una caída. Reorganizar el archivo de recuperación para mejorar el desempeño en la recuperación. Recobrar espacio de almacenamiento en el archivo de recuperación.

Listas de Intención y Archivos de Recuperación
Usadas para que cada servidor mantenga el registro de los ítemes de datos accedidos por las transacciones. Durante el progreso de la transacción las operaciones de actualización son aplicadas a un conjunto privado de versiones tentativas. Cada servidor registra una lista de intenciones de todas sus transacciones activas. Una lista de intención de una transacción particular contiene la lista de nombres y valores de los ítemes de datos que son alterados por tal transacción.

Cuando una transacción se compromete (ejecuta commit), el servidor usa la lista de intenciones de la transacción para identificar los ítems de datos afectados. La versión comprometida de cada ítem de dato es reemplazada por la versión tentativa de tal transacción y el nuevo valor es escrito al archivo de recuperación del servidor. Cuando una transacción aborta, el servidor usa la lista de intención para borrar todas las versiones tentativas de la transacción.

Entradas en el archivo de recuperación : Tipo de entrada Descripción Item de dato Valor del ítem de dato Estado de la Tid, estado de la Transacción Transacción (ready, wait,commit, abort), otros valores. Lista de intención Tid y secuencia de intenciones que consisten de: <id del dato>,<posición del valor del del ítem en archivo de recuperación>

Mecanismos de Recuperación: logging
En esta técnica el archivo de recuperación representa un log que contiene la historia de todas las transacciones realizadas por un servidor. La historia consiste de valores de ítemes de datos, entradas de los estados de la transacción y las listas de intención de la transacción. El orden de las entradas en el log refleja el orden en el cual las transacciones han sido preparadas, comprometidas o abortadas en ese servidor. En la práctica el archivo de recuperación contendrá una foto instantánea de los valores de todos los ítems de datos en el servidor, seguido por una historia de transacciones después de la foto instantánea.

Ejemplo del mecanismo de logging
Transaction T Transaction U bank&retirar(A,4) bank&retirar(C,3) bank&depositar(B,4) bank&depositar(B,3) balance=A.read() $100 A.write(balance-4) $96 balance=C.read() $300 C.write(balance-3) $297 balance=B.read() $200 B.write(balance+4) $204 balance=B.read $204 B.write(balance+3) $207

Ejemplo del mecanismo de logging
Antes de T y U T y U comenzaron P0 P1 P2 P3 P4 P5 P6 P0 Trans T prepared <A,P1> <B,P2> P0 Trans U prepared <C,P5> <B,P6> P4 Dato A 100 Dato B 200 Dato C 300 Dato A 96 Dato B 204 Trans T commit P3 Dato C 297 Dato B 207 checkpoint Apuntadores a la posición del estado previo de la transacción Fin del log

Proceso de recuperación usando logging
Durante la operación normal de un servidor, su administrador de recuperación es llamado cuando: Una transacción se prepara para comprometerse, en cuyo caso adiciona todos los ítems de datos en su lista de intención al archivo de recuperación, seguido por el estado actual (prepared, ready) junto con su lista de intención. Una transacción se compromete o aborta, en este caso adiciona el estado correspondiente a su archivo de recuperación. Se supone que la operación de adicionar una entrada al archivo de recuperación es atómica. Si el servidor falla sólo la última escritura puede estar incompleta.

Proceso de recuperación usando logging
Cuando un servidor es restaurado: a) Coloca los valores iniciales por defecto de sus ítemes de datos. b) Llama al Administrador de Recuperación. c) El Administrador de Recuperación restaura los ítemes de datos del servidor de manera que incluyan todos los efectos de las transacciones comprometidas ejecutadas en el orden correcto y ninguno de los efectos de las transacciones incompletas o abortadas. La información más reciente sobre las transacciones está al final del log, así que el administrador de recuperaciones restaurará los ítemes de datos recorriendo el log desde el final hacia el principio.

Reorganización del archivo de recuperación
El administrador de recuperaciones tiene la responsabilidad de organizar su archivo de recuperación de manera que el proceso de recuperación sea rápido y reducir el uso de espacio. Conceptualmente la única información requerida para la recuperación es una copia de las versiones comprometidas de todos los ítemes de datos del servidor. Checkpointing: se refiere al proceso de escribir los valores actuales comprometidos de los ítemes de datos de un servidor a un nuevo archivo de recuperación, junto con las entradas de los estados de transacción y las listas de intención de las transacciones que aún no han sido resueltas completamente.

Reorganización del archivo de recuperación
Checkpoint : se refiere a la información almacenada por el proceso checkpointing. El propósito de hacer checkpointing es reducir el número de transacciones con las cuales tratar durante la recuperación y recobrar espacio. ¿Cuándo hacer checkpointing? a) Después de una recuperación b) Antes que una nueva transacción comience c) Periódicamente durante la actividad normal del servidor (si el proceso de recuperación no es muy frecuente) El checkpoint es escrito a un archivo de recuperación futuro y el archivo de recuperación actual permanece activo durante el checkpointing.

Proceso de Checkpointing
Archivo de recuperación actual Items de datos del servidor D . . . Pasó durante el chekpointing Archivo de recuperación futuro Marca de checkpoint Foto de D Pasó durante el chekpointing Estados no comprometidos

Mecanismos de Recuperación: versiones sombras
Es una forma alterna de organizar el archivo de recuperación. Usa un mapa para localizar versiones de los ítemes de datos en un archivo llamado almacenamiento de versiones (version store) El mapa asocia los identificadores de los ítemes de datos del servidor con la posición de sus versiones actuales en el archivo de almacenamiento de versiones. Las versiones escritas por cada transacción son son llamadas versiones sombras mientras la transacción no se comprometa.

Mecanismos de Recuperación: versiones sombras
Las entradas de los estados de transacción y las listas de intenciones son salvadas en el archivo de estado de transacción. La lista de intención representa la parte del mapa que será alterada por una transacción cuando se comprometa. Cuando una transacción se compromete, se crea un nuevo mapa copiando el mapa viejo e introduciendo las posiciones de las versiones sombras. Al completarse el compromiso se reemplaza el viejo mapa por el nuevo. Esta operación debe ser atómica.

Ejemplo de versiones sombras
Transaction T Transaction U bank&retirar(A,4) bank&retirar(C,3) bank&depositar(B,4) bank&depositar(B,3) balance=A.read() $100 A.write(balance-4) $96 balance=C.read() $300 C.write(balance-3) $297 balance=B.read() $200 B.write(balance+4) $204 balance=B.read $204 B.write(balance+3) $207

Ejemplo de versiones sombras
Mapa después de T commit Mapa antes de Ty U A --> P0 B --> P1 C --> P2 A --> P3 B --> P4 C --> P2 Archivo de almacenamiento de versiones P0 100 P1 200 P2 300 P3 96 P4 204 P5 296 P6 207 Checkpoint Archivo de estados de transacciones T prepared <A,P3> <B,P4> T committed U prepared <B,P6> <C,P5>

TAREAS ¿Cómo es el proceso de recuperación con la técnica de versiones sombras? ¿Qué pasaría si el servidor se cae entre adicionar un estado committed y actualizar el mapa? Ventajas y desventajas del logging y las versiones sombras.

Tratamiento de Interbloqueos
Condiciones para un bloqueo: 1.- Condición de exclusión mutua. Cada recurso está asignado a un único proceso o está disponible. 2.- Condición de posesión y espera.Los procesos que tienen, en un momento dado, recursos asignados con anterioridad, pueden solicitar nuevos recursos. 3.- Condición de no apropiación. Los recursos otorgados con anterioridad no pueden ser forzados a dejar un proceso. El proceso que los posee debe liberarlos en forma explícita. 4.- Condición de espera circular.Debe existir una cadena circular de dos o más procesos , cada uno de los cuales espera un recurso poseído por el siguiente miembro de la cadena.

Políticas frente a los bloqueos: 1.- Ignorar:el tratamiento del deadlock es responsabilidad del programador y de las acciones. 2.- Detectar: dejar que suceda y luego recuperarse. 3.- Prevenir:Evitar que estructuralmente sea posible el deadlock, es decir, asegurar que al menos una de las cuatro condiciones no se cumpla. 4.- Algoritmo del Banquero: Se necesita conocer los requerimientos de recursos del proceso. (No es aplicable en sistemas distribuidos por su complejidad de conocer los requerimientos de recursos de los procesos con anterioridad).

Se distinguen los siguientes tipos de Deadlocks: 1.- Deadlock de Comunicación: A B C send(B) send(C) send(A) recv(C) recv(A) recv(B) - Si el send es bloqueante entonces estamos en presencia de deadlock. - Este tipo de deadlock es más frecuente en Sistemas Paralelos, pues la filosofía de comunicación es de todos con todos, mientras que en el caso de sistemas distribuidos con la filosofía de cliente-servidor, es menos probable, aun cuando es posible. 2.- Deadlock de Recursos: Es más frecuente en sistemas distribuidos.

Algoritmos de Detección
1.- Centralizado: basado en grafos de espera Máquina 0 Máquina 1 Coordinador T C S B R A S B R A T C S

Algoritmos de Detección
2.- Distribuido: basado en grafo de recursos y procesos. - Asume comunicación confiable. - A los procesos (o transacciones) se les permite pedir varios recursos a la vez. - Cuando un proceso tiene que esperar un recurso ocupado: 1.- Envía un mensaje “Prueba” al que tiene el recurso El mensaje consiste en: .- Número del proceso que tiene que esperar. .- Número del proceso que envía el mensaje. .- Número del proceso que recibe el mensaje. 2.- Cuando un proceso recibe un mensaje de Prueba Si él espera por otro recurso Si recibe (0,X,0) entonces hay Deadlock. - Recuperación: Eliminar una transacción, el proceso decide terminarse (Suicidio: puede inducir a suicidios colectivos innecesarios), seleccionar victima. - ¿Puede suceder deadlock falso?

Algoritmos de Prevención
Se basan en asignar a cada transacción un timestamp: Si una transacción requiere un recurso que otra transacción tiene se chequean los timestamp, y se toma una acción dependiendo de la política seleccionada. 1.- Wait-Die: Vieja Nueva Nueva Vieja Espera Muere 2.- Wound-Wait: Vieja Nueva Nueva Vieja Muere Espera T= 20 T= 10 T= 20 T= 10 Problema: Puede ocurrir inanición ¿Qué sucedería si las transacciones nuevas tienen la prioridad? No es justo. T= 20 T= 10 T= 20 T= 10

TRANSACCIONES DISTRIBUIDAS

Presentaciones similares

Presentación del tema: "TRANSACCIONES DISTRIBUIDAS"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

TRANSACCIONES DISTRIBUIDAS

Presentaciones similares

Presentación del tema: "TRANSACCIONES DISTRIBUIDAS"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback