Procesamiento de Transacciones - LDC Noticiasmcuriel/Cursos/EspecializacionTelematica/Proc... ·...

1

Procesamiento de TransaccionesMaterial basado en los capítulos 12 y 13 del libro: Sistemas Distribuidos. CyD. G. Coulouris, J. Dollimore and T. Kindberg.

Contenido

Definiciones BásicasSincronización Transacciones

Control de Concurrencia:ProblemasEquivalencia SecuencialOperaciones Conflictivas

Contenido

Mecanismos de Control de ConcurrenciaControl de Concurrencia a través de bloqueosControl Optimista de la ConcurrenciaOrdenación por marcas de tiempo

Contenido

Transacciones DistribuidasSistema Manejador de TransaccionesTransacciones Planas y AnidadasCommit y Abort en un Sistema DistribuidoControl de Concurrencia

Por BloqueoOptimistaMarcas Temporales

Contenido

Recuperación de Transacciones

Transacciones

En algunas situaciones, los clientes necesitan que una secuencia de solicitudes separadas al servidor: buscarcuenta, deposita, extrae, obtenerBalance sean atómicas:

Estén libres de interferencia por operaciones de otros clientesTodas las operaciones se deben completar con éxito o no tener ningún efecto si el servidor falla.

2

Transacciones

Provienen de los sistemas de Gestión de BD. En este contexto una transacción es la ejecución de un programa que accede a las BD. Fueron introducidas en los sistemas distribuidos en la forma de servidores de archivos transaccionales (secuencia de operaciones sobre archivos)

Transacciones

Una transacción es una colección de acciones que hacen transformaciones de los estados de un sistema preservando la consistencia del sistemaEl manejo de transacciones puede venir como parte del middleware. Por ejemplo, CORBA, proporciona la especificación para un servicio de transacciones sobre objetos.

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 objetos, o sifalla o es abortada deliberadamente, no tieneningún efecto.

TransaccionesLa propiedad todo-o-nada tiene otros dos aspectos en sí misma:

Atomicidad ante fallas: los efectos son atómicos aun cuando el servidor falla. Los datos que se mantienen en disco deben sobrevivir ante la falla del servidor.Durabilidad: después que una transacción ha terminado exitosamente, todos sus efectos son salvados en almacenamiento permanente.

Transacciones

Transacciones

2. Aislamiento: cada transacción debe ser ejecutada sin interferencias de otrastransacciones, es decir, los resultadosintermedios de una transacción no debenser visibles a otras transacciones.

Estas propiedades también son conocidascomo propiedades ACID

Propiedades ACID

Atomicidad (Atomicity): todo o nada.Consistencia (Consistency): una transacción hace pasar el sistema de un estado consistente a otro. Es generalmente responsabilidad de los programadores de servidores y clientes el asegurar que los datos queden en un estado consistente. Aislamiento (Isolation)Durabilidad (Durability)

3

Propiedades ACIDPara soportar la atomicidad ante fallas y la durabilidad, los objetos de datos deben ser recuperables (estar disponibles en almacenamiento permanente).

Cuando cae un servidor (falla de hardware o software) los cambios de todas lastransacciones que culminaron deben estardisponibles en el almacenamiento permanente. Cuando el servidor sea reemplazado se recuperarán los objetos para reflejar TODO o NADA.

Propiedades ACIDUn servidor que soporta transacciones debe sincronizar las operaciones para asegurar que se satisface el requisito de aislamiento. Una forma de hacerlo es serializando o secuencializando las operaciones. Esto puede ser inaceptable desde el punto de vista del desempeño. La idea de los servidores es maximizar la concurrencia, se permitirá entonces que se entremezclen las transacciones (o sus componentes), si el efecto es el mismo que si se ejecutarán secuencialmente. Es decir son secuencialmente equivalentes.

Condiciones de TerminaciónUna transacción siempre termina, aun en la presencia de fallas. Si una transacción termina de manera exitosa se dice que la transacción hace un commit (consumación)Si la transacción se detiene sin terminar su tarea, se dice que la transacción aborta. Cuando la transacción es abortada, su ejecución se detiene y todas las acciones ejecutadas hasta el momento se deshacen (undone) regresando a la base de datos al estado antes de su ejecución. A esta operación también se le conoce como rollback.

C C C

TransactionManager

scheduler

TPS

RecoveryManager

CacheManager

Data Manager

Estructura de un Sistema de Manejo de Transacciones

El Manejador de Transacciones valida las peticiones de los clientes y pasa la transacción al planificador. El Planificador usa alguna estrategia para permitir una ejecución concurrente que sea secuencialmente equivalente. Manejador de Datos: transferir los datos a memoria principal, escribir actualizaciones, recuperarse ante fallas.

Estructura de un Sistema de Manejo de Transacciones

El manejador de transacciones (Coordinador) dá a cada transacción un identificador TIDOperaciones disponibles al Cliente:

tid BeginTransaction() para el comienzo de una transacción, devuelve el TIDEndTransaction(tid), devuelve abort o commit dependiendo si la transacción se ha podido o no realizarAbort(tid): El cliente puede abortar la transacción.

Estructura de las Transacciones

Planas: consisten de una secuencia de operaciones primitivas encerradas entre las palabras clave Begin Transaction y End Transaction. Por ejemplo,

Begin_transaction Reservación. . .End transaction

4

Estructura de las TransaccionesAnidadas: las operaciones de una transacción pueden ser transacciones

. Por ejemplo,Begin_transaction Reservación. . .

Begin_transaction Vuelo. . .end. {Vuelo}

. . .Begin_transaction Hotel

end {Hotel}

End_transaction Reservación

T: Transacción de Niver Superior

T2:T1:

T11 T12 T21

T211

Commit provisional Commit provisional Commit provisional

Commit provisional

Commit provisional Abort

Commit

Transacciones Anidadas

Una transacción anidada dentro de otra transacción conserva las mismas propiedades que la de sus padres, esto implica, que puede contener así mismo transacciones dentro de ella. Existen restricciones obvias para una transacción anidada:

Debe empezar después que su padre y debe terminar antes que él. El commit de una subtransacción es condicional al commit de su padre, en otras palabras, si el padre de una o varias transacciones aborta, las subtransacciones hijas también serán abortadas.


Las transacciones anidadas proporcionan un nivel más alto de concurrencia entre transacciones. Ya que una transacción consiste de varios transacciones, es posible tener más concurrencia dentro de una sola transacción. Las transacciones de un mismo nivel se pueden ejecutar en forma concurrente pero sus accesos se deben secuencializar.


Las transacciones pueden hacer commit o abort de forma independiente. Cuando una subtransacción aborta, la transacción padre puede elegir una sub-transacción alternativa para completar su tarea.


Reglas para el commit de transacciones anidadas:

Una transacción puede hacer commit o abortsólo después que han terminado las transacciones hijas. Cuando una subtransacción finaliza, decide de forma independiente si hace un commitprovisional o aborta. Una decisión de abortar es definitiva.

5

Transacciones AnidadasReglas para el commit de transacciones anidadas:

Cuando un padre aborta, todas las subtransaccionesabortan (aún cuando éstas hayan realizado un commit provisional)Cuando una subtransacción aborta, el padre puede decidir abortar o no. Si las transacciones de alto nivel hacen COMMIT, se pueden consumar también todas las subtransacciones que hayan realizado un COMMIT provisional. Los efectos de una subtransacción no son permanentes hasta que no se consuma la transacción de nivel superior

T: Transacción de Niver Superior

T2:T1:

T11 T12 T21

T211

Commit provisional Commit provisional Commit provisional

Commit provisional

Commit provisional Abort

Commit

Control de Concurrencia

Las versiones provisionales se transfieren a los objetos sólo cuando una transacción hace commit; en este caso se transfieren también a memoria permanente. Cuando una transacción aborta, sus versiones provisionales se borran.

Control de Concurrencia: Problemas que generan las operaciones conflictivas ejecutándose concurrentemente

Actualizaciones Perdidas

balance = b.obtenBalance(); 200$b.ponBalance(balance*1.1) 220$

c.Extrae(balance/10)

balance = b.obtenBalance(); 200$

b.ponBalance(balance*1.1) 220$a.Extrae(balance/10)

U:balance = b.obtenBalance();b.ponBalance(balance*1.1)c.Extrae(balance/10)

T:balance = b.obtenBalance();b.ponBalance(balance*1.1)a.Extrae(balance/10)

El valor final de B ha debido ser 242$, no 220$. U leyó un valor antes de que T lo actualizara.

El problema viene por paralelizar o pretender que las 2 transacciones se ejecuten concurrentemente cuando deben ejecutarse en forma secuencial.

Recuperaciones Inconsistentes

Total = a.obtenbalance();total = total + b.balance(); // total=300total = total + c.balance():

a.extrae(100) $100

b.Deposita(100) $300

W:Unasucursal.totalSucursal();

V:

a.extrae(100)b.Deposita(100)

/* El valor inicial de ambas cuentas es 200 */

W ve el valor nuevo de a y el Valor viejo de b. No se está cumpliendo lapropiedad de isolation.

6

Control de Concurrencia: Sol. a actualizaciones perdidas.




a.Extrae(balance/10)

-Se puede conseguir equivalencia secuencial secuenciando el acceso al objeto. -La tabla es un ejemplo de secuenciamiento + cierto grado de concurrencia.

Control de ConcurrenciaOperaciones conflictivas: 2 operaciones son conflictivas cuando sus efectos combinados dependen del orden en el cual fueron ejecutadas.

•Se consideran conflictivas las siguientes operaciones: read read no conflictivasread write conflictivaswrite 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.

Control de ConcurrenciaEquivalencia secuencial:

Para cualquier par de transacciones es posible determinar un orden de operaciones conflictivas sobre objetos accedidos por ambas. La equivalencia secuencial se logra de la siguiente forma:a. - Todos los accesos de una transacción a un objeto particular (operaciones conflictivas) deben secuencializarse con respecto a su acceso por otras transacciones.

Control de ConcurrenciaEquivalencia secuencial:

b. Todos los pares de operaciones conflictivas de dos transacciones se deben ejecutar en el mismo orden sobre los objetos a los que ambas acceden. Se requiere:

T acceda i antes que U y T accede j antes que UU acceda a i antes que T y U acceda a j antes que T


Transacciones

Operaciones compuestas

BA C A B C

Serialización de operaciones conflictivas

Operaciones conflictivas

Delay Ejecución

Control de ConcurrenciaT: x=lee(i); escribe(i,10); escribe(j,20)U: y=lee(j); escribe(j,30); z=lee(i)

y = lee(j)Escribe(j,30)

Z=lee(i)

x = lee(i)escribe(i,10)

escribe(j,20)

No es secuencialmente equivalente porque los pares de operaciones conflictivasNo se hacen en el mismo orden en todos los objetos. Aunque si se cumple la Primera condición.

7

Control de Concurrencia: Problemas que generan las operaciones conflictivas

Recuperaciones Inconsistentes

Total = a.obtenbalance();total = total + b.balance;total = total + c.balance():

a.extrae(100) $100

b.Deposita(100) $300

W:Unasucursal.totalSucursal();

V:

a.extrae(100)b.Deposita(100)

/* El valor inicial de ambas cuentas es 200 */

W ve el valor nuevo de a y el Valor viejo de b. No se está cumpliendo lapropiedad de isolation. V accede a antes que W. V accede a b después de W.

Sol. Del problema de Recuperaciones Inconsistentes.

W:

Total = a.obtenbalance();total = total + b.balance;total = total + c.balance():

V:a.extrae(100) $100b.Deposita(100) $300

Control de Concurrencia: Accesos secuencialmente equivalentes.

Los protocolos intentan secuencializar los accesos. Se utilizan tres aproximaciones:

Bloqueo. Control de Concurrencia OptimistaOrdenación por marcas de tiempo.

No obstante pueden aparecer problemas aún en presencia de ejecuciones secuencialmenteequivalentes.

Control de ConcurrenciaLas transacciones pueden abortar, ante esta situación

surgen otros problemas: lecturas sucias y escrituras prematuras

Lecturas SuciasTransacción T Transacción U

a.getBalance() (100$)a.depositar(10) (110$)

a.getBalance() (110$)a.deposita(20) (130$)commit

abortaSe restaura el valor de a a 100. 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)

Lectura Sucia


Una forma de evitar abortos en cascada es sólo permitir a las transacciones leer objetos que fueron escritos por transacciones consumadas.

Control de ConcurrenciaEscrituras Prematuras

105$a.ponBalance(110) 110$

100$a.ponBalance(105) 105$

U:b.ponBalance(110)

T:a.ponBalance(105)

Algunos sistemas de BD implementan la acción Abort restaurando las imágenes Anteriores.

Si U aborta y T se consuma el balance debe ser de 105$. Correcto.U se consuma y T Aborta: El balance debería estar en 110$, pero se coloca la imagen anterior a T que es 100$. La escritura de U es prematura, antes de que T haga su commit.

8


Para garantizar resultados correctos en un esquema de recuperación que utiliza imágenes anteriores, las operaciones de escritura se deben atrasar hasta que las transacciones anteriores que actualizaron los mismos objetos hayan hecho commit o abort (U no debería escribir)


La ejecución de las transacciones se llama estricta si las lecturas o escriturasde los objetos se retrasa hasta quetodas las transacciones quepreviamente escribieron el objeto hayanhecho commit o abort. La ejecuciónestricta de las transacciones hacecumplir la propiedad de aislamiento.


Para que un servidor está en capacidad de deshacer cambios si una transacción aborta, debe diseñarse de forma que las actualizaciones puedan ser eliminadas.Todas las operaciones de actualización se hacen sobre versiones provisionales de los objetos en memoria volátil.A cada transacción se le proporciona su conjunto privado de versiones provisionalesde los objetos que ha alterado.

Contenido

Mecanismos de Control de ConcurrenciaControl de Concurrencia a través de bloqueosControl Optimista de la ConcurrenciaOrdenación por marcas de tiempoComparación de métodos.


Control de Concurrencia: Bloqueos




a.Extrae(balance/10)

-Se puede conseguir equivalencia secuencial secuenciando el acceso al objeto. -La tabla es un ejemplo de secuenciamiento + cierto grado de concurrencia.

-Una forma sencilla de secuenciar es a través del uso de bloqueos exclusivos.


Nivel de granularidad: 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.Mientras mayor sea la fineza del 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)

9


Cada vez que un proceso necesita leer o escribir en un objeto como parte de unatransacción, el objeto se bloquea hasta quela transacción culmine exitosamente(commit). Cualquier otra transacción quedesee hacer alguna operación sobre dichoobjeto tendrá que esperar hasta que él sea desbloqueado.

Control de Concurrencia: Problemas que generan las operaciones conflictivas

Para lograr equivalencia secuencial, todos los pares de operaciones conflictivas se deben hacer en el mismo orden.Para asegurar esto, no está permitido a una transacción ningún nuevo bloqueo después que ha liberado alguno. Existen dos fases:

Adquirir bloqueos (Fase de crecimiento)Liberar bloqueos (Fase de Acortamiento)

Algoritmo de locking o bloqueoTwo 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). Desventaja: si una transacción en la fase de liberación había desbloqueado algunos objetos y los mismos habían sido accedidos por otras transacciones antes de que la primera hiciera commit, entonces las demás transacciones deberían abortar (esto es abortos en cascada). Pudiera ocurrir: lecturas sucias o escriturasprematuras

Algoritmo de locking o bloqueoPara evitar esto, se mantienen todos losbloqueos aplicados a los objetos hasta que la transacción que los posee se consuma (commit) o aborte. Esto se llama Bloqueo en dos fasesestricto.

La fase de “liberación” se realiza sólo cuando la transacción hace commitVentaja: evita los abortos en cascadaDesventajas:

El nivel de paralelismo se degradaEn algunos casos es inadmisible.

Algoritmo de locking o bloqueoTwo Phase Locking Strict Two Phase Locking

number of locks

Time

Fase de crecimiento Fase de liberación

number of locks

Time

Fase de crecimiento Fase de liberación

Se liberantodos loslocks


Para mejorar la concurrencia, la porción de objetos a la que se debesecuenciar el acceso debe ser tan pequeño como sea posible. Problema de los lectores o escritores.

10

Algoritmo de locking o bloqueo

lock otorgado lock solicitadoNinguno read OK - write OKread read OK - write Esperawrite read Espera - write Espera

• Una mejora: utilizar locks de escritura y locks de lectura para ofrecer un mejor paralelismo al permitir que se realicen concurrentemente transacciones que hagan operaciones no conflictivas.


Se toma un lock de lectura, y se promueve a un bloqueo de escritura cuando se va a escribir sobre el mismo objeto. Cuando una transacción posterior desea leer, debeesperar hasta que se libere el lock de escritura.


Para asegurar que se sigan las reglasde solicitud de bloqueos para losobjetos , el cliente no tiene acceso a lasoperaciones de bloqueo. Los locks son adquiridos y liberados por el administrador de transacciones. Todo lo concerniente al control de concurrenciaes transparente para el programador.

Bloqueo para Transacciones Anidadas

El proposito de un esquema de bloqueo es serializar el acceso a los objetos de modo que:

1. Cada conjunto de transacciones anidadas sea la única entidad a la que se debe impedir ver los efectos de otro conjunto de transacciones anidadas2. Se debe impedir que cada transacción en un conjunto de transacciones anidadas observe los efectos parciales de otras transacciones del conjunto.


La primera regla se logra disponiendo que cada bloqueo que adquiere una subtransacción es heredado por su padre cuando esta finaliza. Esto garantiza que puedan mantenerse los bloqueos hasta que se haya consumado o abortado la transacción a nivel superior.


La segunda regla se hace cumplir así:No se permite la ejecución concurrente de padre e hijos. Si una transacción padre tiene un bloqueo sobre el objeto, retiene el bloqueo mientras el hijo se ejecuta. La transacción hijo adquiere temporalmente el bloqueo. Se permite la ejecución concurrente de transacciones al mismo nivel, por lo que cuando éstas accedan a los mismos objetos el esquema de bloqueo debe secuenciar el acceso.

11


El problema del algoritmo de bloqueo es quepuede ocasionar deadlocks o Interbloqueos.

b.Deposita() bloqueo de escritura para B

a.extrae(200) Espera por T.Bloquea en A

a.Deposita() bloqueo de escritura para A

b.extrae Espera por UBloqueo en B

UT

InterbloqueosCondiciones 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.

T U T U

R1

R2

Espera por

Espera por

Poseído por

Poseído por

Grafo de Espera Circular: Si hay un ciclo en el grafo significa que hay interbloqueo.

Tratamiento de InterbloqueosPolíticas frente a los bloqueos:

1.- Detectar: dejar que suceda y luego recuperarse.3.- Evitar que estructuralmente sea posible el deadlock,

es decir, asegurar que al menos una de las cuatro condiciones no se cumpla. (EM, NApropiación, H and W, Circular Wait)

4.- Predecir: 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).

Tratamiento de InterbloqueosPolíticas frente a los bloqueos:

1.- Detectar:Se pueden detectar a través de los grafos.Una vez detectado el ciclo se debe escoger una

transacción y abortarla. La elección de la transaccióna abortar no es sencilla. Un factor que puede ser tomado en cuenta es su edad.

La presencia de ciclos en el grafo se puede detectarcada vez que se añade un arco o cada cierto tiempopara disminuir el overhead.

• Se basan en asignar a cada transacción un timeout:

• A cada bloqueo se le proporciona un tiempolimitado en el que es invulnerable. •Después de ese tiempo es vulnerable. •Si ninguna transacción está compititnedo por el objeto, un objeto con bloqueo vulnerable continua bloqueado. •Sin embargo, si cualquier otra transacción estáesperando por acceder a un objeto con un bloqueovulnerable, se rompe el bloqueo y se reanuda la transacción que esperaba. La transacción cuyobloqueo se ha roto, normalmente aborta.

Algoritmos de Prevención

12

Bloqueos

Causan overhead en el manejo de bloqueos y en los algoritmos de prevención o deteccciónDisminuyen la concurrencia. Otros esquemas (Ver en el material de apoyo)

Bloqueo de Versiones Jerárquico

Contenido

Mecanismos de Control de ConcurrenciaControl de Concurrencia a través de bloqueosControl Optimista de la ConcurrenciaOrdenación por marcas de tiempoComparación de métodos.


Algoritmo OptimistaSe permite que las transacciones procedan como si no

hubiera posibilidad de conflicto con otras transacciones hastaque el cliente complete su tarea y solicite un EndTransaction. Cuando aparece un conflicto se abortará la transacción.

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).

Algoritmo OptimistaCada transacción cumple tres fases:

Trabajo:Todos los reads se ejecutan inmediatamente sobre la última versión “consumada” 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”, sólo se leen

valores consumados.Validación: Ante la solicitud de un commit, se valida si

la transacción realizó operaciones conflictivas con otras transacciones. Si la validación tiene éxito se puede hacer COMMIT. Si falla, se debe usar algunaforma de resolución de conflictos (abortar alguna de las transacciones)

Algoritmo Optimista

Escritura: Si la transacción es validada, todos los cambios hechos sobre los espaciosprivados se actualizan en las versionesoriginales.

Algoritmo Optimista

Fase de validación:

Ante el End_transaction, a cada transacción se le asigna un número (secuencial ascendente, i) que define su posición en el tiempo.

13

Algoritmo OptimistaFase de validación:

La validación se basa en las siguientes reglas :Tv Ti Regla (i<v)

1. write read Ti no debe leer datos escritos por Tv2. read write Tv no debe leer datos escritos por Ti3. write write Ti no debe escribir datos que está escribiendo o

haya escrito Tv y

Tv no debe escribir datos que está escribiendo o haya escrito Ti

Simplificación: fases de validación y escritura son secciones críticas (muy cortas), se supondrá que no puedensolaparse 2 transacciones en estas fases; se satisface la regla 3. Sólo hay que validar las reglas 1 y 2

Algoritmo OptimistaValidación hacia atrás:

Los reads de las Ti se realizaron antes que la validación (por tanto escritura) de Tv, entonces se cumple la regla 1.Sólo se valida la regla 2 para cada Ti:

valid= true;for (Ti=startTn+1;Ti<=finishTn,Ti++) {

if (“read_set” of Tv intersects “write_set” Ti)valid=false;

}


startTn: Ti más grande asignado a una transacción committed al momento que Ti entra a su fase de trabajo. finishTn: Ti más grande asignado al momento que Ti entra a su fase de validación

Sólo es necesario validar los conjuntos de lectura. Las transacciones que sólo hacen escritura no se validan (lo que ella escriba lo validarán otras transacciones mayoresposteriormente).

Si Tv no es válida, se aborta


T1T2

T3Tv

activa1

activa2

Transaccionesanteriores committed

Transacción en validación

Trabajo Validación

Escritura

Algoritmo Optimista

Validación hacia atrás: precisa que los conjuntos de escritura de las versiones antiguas de los objetos ya consumadas sean retenidas hasta que no hayan transacciones solapadas, aún no validadas, con la que pudieran entrar en conflicto. En un entorno con transacciones largas, el mantener estos conjuntos puede ser un problema.

Algoritmo Optimista

Validación hacia adelante: el conjunto de escritura de Tv se compara con el conjunto de transacciones activas que se solapan, aquellas que están aún en su fase de trabajo.

14

Algoritmo OptimistaFase de validación:

La validación se basa en las siguientes reglas :Tv Ti Regla (v<i)

1. write read Ti no debe leer datos escritos por Tv2. read write Tv no debe leer datos escritos por Ti3. write write Ti no debe escribir datos que está escribiendo o

haya escrito Tv y

Tv no debe escribir datos que está escribiendo o haya escrito Ti

Validación hacia adelante:

Se satisface la regla 2 porque las transacciones activas no escriben mientras que Tv no se ha completado.Sólo se valida la regla 1 para cada Ti: se compara el conjunto de escritura de Tv con los conjuntos de lecturade las transacciones activas.

valid= true;for (Tid=activa1;Tid<=activaN,Tid++) {

if (“write_set” of Tv intersects “read_set” of Ti)valid=false;

}

Algoritmo Optimista

Validación hacia delante:

activaX: Representan transacciones que aún no han entrado a la fase de validaciónLas transacciones que sólo hacen lecturas no requieren ser validadasSi Tv no es válida:

Abortar las activas y consumar TvAbortar Tv

Algoritmo Optimista Algoritmo OptimistaValidación hacia adelante:

T1T2

T3Tv

activa1

activa2

Transaccionesanteriores committed

Transacción en validación

Trabajo Validación

Escritura

Algoritmo OptimistaDesventajas:

Hay posibilidad se inanición: una transacción puede abortar indefinidas veces y no se contempla un mecanismo para evitarlo. Este algoritmo no serviría para nada en sistema con transacciones largas, muchas transacciones en conflicto.

Algoritmo por Marcas de TiempoLas operaciones se validan al momento de ser ejecutadas.

Cuando una transacción comienza, se le asigna un timestamp

La regla de ordenación básica por marca de tiempo estábasada en los conflictos de operación:

Una solicitud de una transacción para escribir un objetoes válida sólo si ese objeto fue leído y escrito porúltima vez por transacciones anteriores en el tiempo.

Una petición de lectura a un objeto es válida sólo si el objeto fue escrito por última vez por una transacciónanterior.

15

Algoritmo por Marcas de TiempoSe trabaja con versiones tentativas. Las versiones

tentativas de los objetos son consumadas en el ordendeterminado por las marcas de tiempo de las transaccionesque las realizaron.

Cada item de datos tiene asociado:Un timestamp de escritura (Twrite_commit), un timestampde 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 timestampmenor que el timestamp de la transacción

Algoritmo por Marcas de TiempoPara saber cuando una operación de escritura es válida se

aplica el siguiente algoritmo:

Sea Tj una transacción que desea hacer una operación de escritura 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, con marca de tiempo Tj

else // write is too lateAbortar Tj;

Algoritmo por Marcas de TiempoRegla de escritura (No se muestran las marcas de lectura)

a) T3->write b) T3-> write

c) T3->write d) T3-> write

T2

después

antes

T2 T3

T1

después

antes

T1 T2

T2

T3

T1

después

antes

T1 T3

T4

T4

T4

después

antes

T4

T3 Aborta

Versióntentativa

Versióncommitt

Algoritmo por Marcas de TiempoPara saber cuando rechazar o aceptar inmediatamente una

operación de lecturaSea Tj una transacción que desea hacer un read sobre el objeto

D.If ((Tj > Max (Write_Commit en D))

Sea Ds la versión de D con la máxima marca de tiempo de escritura menor a Tj (commited o no)

Si se ha consumado Ds: realiza la operación de lectura.Si no, espera hasta que la transacción que hizo la versión

Ds haga commit o abort.else // write is too late

Abortar Tj;

Algoritmo por Marcas de TiempoRegla de lectura

a) T3->read b) T3-> read

c) T3->read d) T3-> read

T2 T2 T4

T1 T2 T4 T3 Aborta

Versióntentativa

Versióncommitt

Seleccionado(Ds)

read se ejecutainmediatamente

Seleccionado(Ds)

read se ejecutainmediatamente

Seleccionado(Ds)

read espera

Algoritmo por Marcas de TiempoLas versiones commit (consumadas) de cada objeto deben crearse en el orden de las marcas de tiempo. Un coordinador necesita esperar, a veces, que se completen las transacciones anteriores antes de escribir todas las versiones consumadas de los objetos.

16

MTL MTE{} S

S,U

MTL MTE{} S{T}

S,T

T{U}

T,U

MTL MTE{} S

S,TT

BeginTBal=b.obtenBalance()Espera por T….…Bal=b.obtenBalance()b.ponBalance()

c.Extrae()

beginTBal=b.obtenBalance()b.ponBalance(bal*1.1)

a.Extrae()Commit

cbaUT

Algoritmo por Marcas de Tiempo

La última marca de lecturaCorresponde a la transacción T

S < T < U. En negritas se colocan las operaciones ya consumadas

Ejercicio

BeginTescribe(i,55)escribe(j,66)

Commit

BeginT

X=lee(i)Escribe(j,44)

UT

BeginTEscribe(i,55)Escribe(j,66)commit

BeginT

X=lee(i)Escribe(j,44)

UT

Corra el algoritmo de secuenciación por marcas de tiempo. Las marcas de tiempo iniciales de lectura y escritura son t0.

BeginT

Escribe(i,55)Escribe(j,66)

Commit

BeginTy = lee(k)

x = lee(i)

Escribe(j,44)Commit

UT

Qué pasa cuándo va a terminar la transacción T si corremos el algoritmo Optimista con validación hacia atrás, hacia adelante???

EjercicioUn servidor gestiona los objetos a1, a2, …an. El servidor proporciona a sus clientes Dos operaciones:

Lee(i) devuelve el valor de aiEscribe(i,valor) asigna el valor “valor” a ai

Las transacciones T y U se definen como sigue:T: x= lee(i); escribe(j,44)U: escribe(i,55); escribe(j,66)

1. Cómo funciona o escriba una secuencia de ejecución con bloqueo estricto de dosfases.2. Describa un solapamiento de las transacciones T y U en el que los bloqueos se Liberan prontamente y se obtiene un efecto que no es secuencialmenteequivalente.

Transacciones Distribuidas

Contenido

Transacciones DistribuidasTransacciones Planas y AnidadasCommit y Abort en un Sistema DistribuidoControl de Concurrencia

Por BloqueoOptimistaMarcas Temporales

Recuperación

17


Sus actividades involucran múltiplesservidores.Se usa el término transacciones distribuidas para referirse a transacciones planas o anidadas que acceden a objetos administrados por múltiples servidores.

Las transacciones distribuidas pueden ser planas o anidadas.

Cliente:

begin_transactioncall X.xcall Y.ycall Z.z

end_transaction

cliente

X

Z

YTransacción Plana: Un cliente realiza peticiones a más de un servidor.Las peticiones son secuenciales


Transascción distribuida anidada: las transaccionesdel mismo nivel son concurrentes. Si están en Servidores distintos pueden ejecutarse en paralelo.

T

Cliente

XT1

YT2

MT11

PT22

NT12

T21

Transacciones AnidadasSea una transacción distribuida donde el cliente transfiere

$10 de la cuenta A a C y $20 de B a D. Las cuentas A y B están separadas en servidores X e Y y las cuentas C y D están en el servidor Z.

Si la transacción se estructura como un conjunto de cuatro transacciones anidadas, los cuatro requerimientos ( dos depósitos y dos retiros) pueden correr en paralelo y el efecto total es lograr mayor rendimiento que una transacción simple ejecutando las cuatro operaciones secuencialmente.

Procesamiento de transaccionesdistribuidas

Un cliente comienza una transacciónenviando un begin_transaction a cualquierservidor TPS. Éste se convierte en el coordinador y los que se tengan quecontactar a partir de aquí se convierten en participantes.

18

C

D

B

AbeginTransactionendTransaction

Cliente

Unirse

Unirse

Unirse

b.extrae(T,3)

Coord.

a.extrae(4)

b.extrae(3)

c.deposita(4)

d.deposita(3)SucursalZ

SucursalY

SucursalX

Nota: el coordinador está en uno de los Servidores, por ejemplo SucursalX


El coordinador que inició la transacción es el responsable final de consumarla o abortarla.Durante el progreso de una transacción el coordinador registra la lista de referencias de participantes, y cada participante registra una referencia hacia el coordinador.


La operación BeginTransaction devuelve el TID. Los identificadores de las transacciones deben ser únicos dentro del sistema distribuido. Una forma sencilla de obtener identificadores únicos esto es que cada TID tenga dos partes: el identificador del servidor (e.g. dirección IP) y un número único dentro del servidor.


Existen dos aspectos importantes a considerar en las transacciones distribuidas:

La consumación de una transacciónControl de concurrencia

Se supone que existe una comunicación entre TPSs a través de un protocolo de aplicación. Estos protocolos se implementan sobre RPC o pase de mensajes.


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)Las transacciones distribuidas deben ser globalmente serializadas. Existen protocolos de control de concurrencia distribuida.

Protocolos de Consumación Atómica

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.

19

Consumación en una faseCommit de una fase atómico

Una manera simple de completar una transacciónen forma atómica por el coordinador escomunicar el requerimiento de commit o abort (por parte

del cliente)a todos los participantes de la transacción ymantenerse enviando el requerimiento hastaque todos ellos respondan con un ACK indicando que han

realizado la tarea.

El protocolo no contempla quela decisión de abortar venga de uno de los participantes. Sólo puede venir del

cliente.

Consumación en Dos FasesPermite que cualquier participante aborte su parte de la transacción. En la primera fase del protocolo cada participante vota para que la transacción sea consumada o abortada. Una vez que el participante ha votado commit, no se le permite que aborte. Por lo tanto, antes de un participante votar por commit debe asegurarse que será capaz de llevar a cabo su parte del protocolo de consumación, incluso si falla. Se dice que un participante está en estado “preparado”si finalmente será capaz de consumar la transacción en proceso.

Consumación en Dos Fases

En la segunda fase: El coordinador recoge el resultado de las votaciones. Si alguno de los participantes vota por abortar, la decisión es abortar. Si todos los participantes votan consumar, esta será la decisión.

Consumación en Dos Fases

Si uno de los participantes o el Cliente decide abortar (antes de la solicitud del coordinador) se le informa al resto. No se activa el protocolo de consumación.

Protocolo de Consumación en dos FasesFase 1 (votación)

1. El Coordinador envía una petición (commit?) a cada participante en la transacción2. Cuando un participante recibe una petición commit? Responde al Coordinador con su voto (si o no). Antes de votar Sí se prepara para hacer commitguardando los objetos en almacenamiento permanente. Si el voto es No. El participante aborta de forma inmediata.

Protocolo de Consumación en dos FasesFase 2 (finalización en función del resultado de la votación)

3. El coordinador recoge los votos (incluyendo el propio)Si no hay fallos y todos los votos son Sí, el coordinador decide consumar la transacción y envía peticiones de COMMIT a cada uno de los participantes. En otro caso, el Coordinador decide abortar la transacción y envía peticiones Aborta a todos los que votaron Sí.

4. Los participantes que han votado Sí están esperando por una petición de Commit o Abort por parte del Coordinador. Cuando se reciben uno de estos mensajes, se actúa en función de ellos. En caso de COMMIT se retorna al servidor:haveCOMMITTed.

20

Protocolo de Consumación en dos Fases

El protocolo podría fallar debido a la caída de uno o más servidores o debido a un corte en la comunicación.Para cubrir la posibilidad de caidas, cada servidor guarda la información correspondiente al protocolo en un dispositivo de almacenamiento permanente. Esta información la puede recuperar un nuevo proceso que se inicie para reemplazar al servidor caído.

Situación en la que un participante ha votado Sí y estáesperando para que el coordinador le informe el resultado de la votación Fallas en la Comunicación

Situación en la que un participante ha votado Sí y estáesperando para que el coordinador le informe el resultado de la votación:

El participante está incierto frente al resultado y no puede seguir adelante hasta que obtenga los resultados de la votación por parte del coordinador. No puede decidir unilateralmente, debe mantener los objetos. Envía un mensaje al Coordinador de DameDecision. Cuando obtiene la respuesta continua en el paso 4 del protocolo. Si el Coordinador ha fallado el participante no podráobtener una decisión hasta que el servidor sea reemplazado.

Acciones frente a un timeout

El participante ha realizado todas sus tareas y aún no ha recibido el llamado Puede Consumar?? (primera comunicación)

En este caso, como no se ha tomado ninguna decisión el participante puede decidir unilateralmente abortar.

Acciones frente a un timeout

El coordinador puede sufrir retrasos cuando estáesperando por los votos de los participantes.

Dado que no está decidido el destino de la transacción, tras cierto periodo de tiempo puede abortar. En ese momento, el Coordinador anuncia su decisión a todos los participantes que ya habían votado. Algunos participantes retrasados pudieran votar Sí, sin haber recibido el último mensaje del coordinador. El coordinador ignora este Sí y el participante pasa al estado incierto.

21


T

T2

T1

T11

T12

T21

T22

Aborta en M

Cons. Provisional (en X)

Cons. Provisional (en N)


Cons. Provisional (en P)

Abortado (en M)T

Cliente

XT1

YT2

M

T11

PT22

NT12

T21


Cuando finaliza una subtransacción toma una decisión independiente sobre si consumarse de forma provisional (no es lo mismo que estar preparado) o abortar. Una consumación provisional es simplemente una decisión local y no se guarda copia en un dispositivo de almacenamiento permanente. Las transacciones trabajan y, cuando terminan, el servidor donde se encuentran registra información sobre si se han consumado provisionalmente o han abortado.


Cuando una transacción anidada se consuma en forma provisional informa de su estado y del estado de sus descendientes a su madre. Cuando una transacción aborta, simplemente informa de haber abortado a su madre. Al final, la transacción a nivel superior recibe una lista de todas las subtransacciones en el árbol junto con el estado de cada una de ellas.


La transacción a nivel superior juega el papel de Coordinador en el protocolo de consumación en 2 fases.


T

T2

T1

T11

T12

T21

T22

Aborta en M

Cons. Provisional (en X)



Cons. Provisional (en P)

Abortado (en M)

La lista de participantes consta de los servidores de todas las subtransacciones que se hayan consumado provisionalmente pero no tienen ascendentes que hayan abortado: T, T1, T12

22


La transacción a nivel superior debe intentar consumar lo que quede del árbol. A T1 y T12 se les pedirá que voten para obtener el resultado. Si votan consumar deben preparar las transacciones guardando el estado de los objetos en el dispositivo de almacenamiento permanente. La segunda fase es idéntica: se recogen los votos y se informa a los participantes en función del resultado.

Control de Concurrencia: BloqueosEn una transacción distribuida los bloqueos se mantienen localmente (en el mismo servidor).El administrador local de bloqueos puede decidir si otorga un bloqueo o hace que la transacción que lo requirió espere.Sin embargo no puede liberar ningún bloqueo mientras la transacción que los tiene no haya terminado (commito abort) en todos los servidores involucrados en la transacción. Cuando se usa el bloqueo para control de concurrencia, los objetos permanecen bloqueados y no están disponibles para otras transacciones durante el protocolo de commit atómico, aunque una transacción abortada libere sus bloqueos durante la primera fase del protocolo.

BloqueosDado que los administradores de bloqueos en diferentesservidores otorgan bloqueos independiente de los demás,es posible que diferentes servidores impongan diferenteorden sobre las transacciones.

Considérese el siguiente entrelazado de las transaccionesT y U en los servidores X e Y:T UWrite(A) en X lock A

Write(B) en Y lock BRead(B) en Y espera U

Read(A) en X espera por T

El objeto A está en el servidor X y el objeto B en el servidor Y

Bloqueos

Se tiene T antes que U en un servidor y U antes que T en

el otro.Cuando se detecta una condición de interbloqueo las transacciones son abortadas.En este caso el coordinador será informado y abortará las transacciones en los participantes involucrados.

Algoritmos de Detección1.- Centralizado: basado en grafos de espera

Máquina 0 Máquina 1 Coordinador

S

B

R

A

T

CS

T

CS

B

R

A

Cómo se mantiene el grafo en el coordinador ?• Cada vez que ocurra una variación en su grafo notifica al coordinador .• Periodicamente cada máquina notifica sus últimos cambios .• Periodicamente el coordinador solicita la información.

Problema: Los 3 casos pueden conducir a un Deadlock falso.

Ejemplo: Si se pierden mensajes

Si B solicita a T y C libera a T y llega primero el mensaje de B alcoordinador, entonces el cree que hay deadlock.

Transacciones Recursos

Algoritmo Distribuido (Caza de Arcos)

En esta aproximación el grafo no se construye en forma global, sino que cada uno de los servidores implicados posee información sobre alguno de sus arcos. Los servidores intentan encontrar ciclos mediante el envío de mensajes denominados sondas.

23

Pasos del Algoritmo

Iniciación: Cuando un servidor percibe que una transacción T, espera por un recurso que tiene una transacción U (que está en otro servidor), inicia el algoritmo enviando una sonda que contiene el arco <T->U> al servidor que contiene el objeto por el cual está bloqueada la transacción U. Si U está compartiendo el bloqueo (varias transacciones acceden al mismo objeto), se envía la sonda a los servidores responsables de estas transacciones

Pasos del Algoritmo

Detección: consiste en recibir sondas y decidir si se ha producido inter-bloqueo.

Por ejemplo, si un servidor recibe la sonda <T->U> (T espera por U, que tiene el bloqueo de un objeto local), comprueba si U está también esperando. Si es así, se añade a la sonda la transacción por la que está esperando, ej, V. <T->U->V>, y si V está esperando por un objeto en otro sitio se vuelve a reenviar la sonda.

Pasos del Algoritmo

Detección: Antes de reenviar la sonda, el servidor comprueba si la transacción que ha sido añadida, ej, T

<T->U->V->T> Ha ocasionado un ciclo, si es así se ha

detectado un interbloqueo.

Pasos del Algoritmo

Resolución: cuando se detecta un ciclo, se aborta una transacción en el ciclo para romper el interbloqueo.

Algoritmo de Detección de Bloqueos DistribuidoEl coordinador de una transacción es responsable

de registrar si la transacción está activa o estáesperando por un objeto concreto, y los participantes pueden obtener esta información desde su coordinador. Los gestores de bloqueos informan a los coordinadores cuando las transacciones comienzan a esperar por objetos, y en el momento que adquieren dichos objetos para comenzar a estar activas.

Algoritmo de Detección de Bloqueos DistribuidoCuando se aborta una transacción para

romper un inter-bloqueo, el coordinador informará a los participantes y se eliminarán todos sus bloqueos, con el efecto de que todos los arcos relacionados con esta transacción se eliminarán de los grafos espera-porlocales.

24

Control de Concurrencia Optimista

Recordar: Cada transacción se valida antes de que se le permita consumarse. Se asignan unos números de transacción al comienzo de la validación y se establece un orden o secuencia de acuerdo a estos números.


Una transacción Distribuida es validada por una colección de servidores independientes, cada uno de los cuales valida las transacciones que acceden a sus propios objetos. La validación de todos los servidores tiene lugar durante la primera fase del protocolo de consumación de dos fases.


En el caso de transacciones distribuidas optimistas, cada servidor aplica en paralelo un protocolo de validación. Esta es una extensión de la validación hacia delante o hacia atrás para permitir que varias transacciones estén en la fase de validación (por lo que pueden tardar estas fases en un entorno distribuido).

En esta extensión se debe comprobar tanto la regla 3 como la regla 2 ó 1.

Control de Concurrencia OptimistaSean las transacciones T y U entrelazadas,

las cuales acceden a los objetos A y B en los servidores X e Y respectivamente:

T URead(A) en X Read(B) en YWrite(A) Write(B)Read(B) en Y Read(A) en XWrite(B) Write(A)


Las transacciones acceden a los objetos en el orden Tantes que U en el servidor X y U antes que T en elservidor Y.

Si se supone que T y U empiezan la validación al mismotiempo, el servidor X valida T primero y el servidor Yvalida U primero. No se cumple la equivalencia secuencial


Los servidores de transacciones distribuidas deben evitar que suceda T antes que U en un servidor y U antes que T en otro.

Sol: después de una validación local, se llevará a cabo una validación global (antes de la consumación). La validación global comprueba que el orden en los servidores sea secuencialmente equivalente.

25

Control de concurrencia con ordenación de Marcas Temporales.

En transacciones distribuidas se requiere que cadacoordinador genere una única marca de tiempoglobal.

Se consigue la equivalencia secuencial consumando las versiones de los objetos en el orden de las marcas temporales de las transacciones que acceden a ellos. Se requiere que cada coordinador genere marcas temporales que sean globalmente únicas. Esta marca de tiempo es dada al cliente por el primer

coordinador accedido por la transacción.

Time Stamps

La marca de tiempo de la transacción se pasa alcoordinador de cada servidor en los cuales se

realizan operaciones de la transacción.

Una marca temporal consta de: <marca temporal local, identificador local del servidor>

Time Stamps

Se requiere que las marcas de tiempo proporcionadas por un coordinador estén aproximadamente sincronizadas con aquellas que emiten otros coordinadores. Las marcas se pueden mantener sincronizadas mediante la utilización de algoritmos de sincronización de relojes.

Recuperación Distribuida

Hemos supuesto que: Cuando un servidor estáen funcionamiento, mantiene todos sus objetos en la memoria volátil y registra sus objetos consumados en un archivo o archivos de recuperación. La recuperación consiste en restaurar el servidor a partir de los dispositivos de almacenamiento permanente y dejarlo con las últimas versiones consumadas de los objetos.


Los requisitos de persistencia y atomicidad ante fallos se tratan mediante un único mecanismo: el gestor de recuperación. Las tareas de un gestor de recuperación son:

Guardar los objetos de todas las transacciones consumadas en dispositivos de almacenamiento permanente.Restaurar los objetos del servidor tras una caída.


Reorganizar el archivo de recuperación para mejorar el rendimiento de la recuperación. Reclamar espacio de almacenamiento.

Se requiere que el gestor de recuperación sea resistente a los fallos en los medios (discos, etc). Se debe manejar al menos una copia del archivo de recuperación.

26

Recuperación DistribuidaListas de Intenciones:

Durante el progreso de una transacción, las operaciones de actualización se aplican sobre un conjunto privado de versiones tentativas de los objetos que pertenecen a la transacción.En cada servidor se guarda una lista de intenciones para cada una de sus transacciones activas.


La lista de intenciones de una transacción contiene una lista de las referencias y los valores de los objetos que son alterados durante la transacción. Cuando una transacción se consuma se utiliza la lista de intenciones para identificar los objetos afectados. Se reemplaza la versión tentativa del objeto por una versión consumada.


En el protocolo de consumación de dos fases un participante dice que está preparado para hacer COMMIT.Cuando un participante dice que está preparado para hacer un commit, su gestor de recuperación debe haber guardado en su archivo de recuperación su lista de intenciones, de tal forma que después pueda llevar a cabo el commit, aún si fallara el servidor donde reside.


Entradas del Archivo de Recuperación:Objeto: el valor del objetoEstado de la transacción: Identificador de la transacción, estado de la transacción (preparada, consumada, abortada) Lista de intenciones: Identificador de la transacción y una secuencia de intenciones, cada una de las cuales consiste en: identificador del objeto, posición en el archivo de recuperación.

Registro Histórico

El archivo contendrá una instantánea reciente de los valores de todos los objetos seguido de un historial de las transacciones. Cuando el servidor está preparado para consumar una transacción, el gestor añade al archivo todos los objetos en su lista de intenciones seguido por el estado actual de la transacción (preparada).Cuando una transacción se consuma o aborta, se añade un nuevo registro con el estado de la transacción

Registro Histórico

P0 P1 P5P2 P4P3 P7P6

Objeto: A100

Objeto: B200

Objeto: C300

Objeto: A80

Objeto: B220

Trans: TPreparada<A,P1><B,P2>

P0

Trans:TConsumada

Objeto: C278

Objeto: B242

Trans: UPreparada<C,P5><B,P6>

P4

27

Registro Histórico

Tras una caída se aborta cualquier transacción que no tenga el estado de consumada. Cada entrada del estado de una transacción contiene un apuntador a la posición en el archivo de recuperación de la entrada que contiene el estado anterior a la transacción.

Registro Histórico

Aproximaciones para restaurar:Desde el comienzo del archivo. Las transacciones se repiten en el orden en el cual fueron ejecutadas.Se recuperan los objetos leyendo el archivo de recuperación hacia atrás. Se utilizan las transacciones de estado consumadas para restaurar objetos que no han sido restaurados. Cada objeto sólo se restaura una vez.

Registro Histórico

P0 P1 P5P2 P4P3 P7P6

Objeto: A100

Objeto: B200

Objeto: C300

Objeto: A80

Objeto: B220

Trans: TPreparada<A,P1><B,P2>

P0

Trans:TConsumada

Objeto: C278

Objeto: B242

Trans: UPreparada<C,P5><B,P6>

P4

En el ejemplo la recuperación se hará así:Comienza en P7, concluye que U no se ha consumado y sus efectos se deben borrar.Se mueve a P4 y concluye que T se había consumado. Se mueve a P3 y restaura A y B a partir de la lista de intenciones. Ya que no ha restaurado C se mueve hacia P0, que es el punto de control y restaura C.

Versiones Sombra

Es una forma alternativa de organizar el archivo de recuperación. Utiliza un mapa para localizar las versiones de los objetos dentro de otro archivo. Cuando una transacción está preparada para hacer commit, se añaden los objetos cambiados al almacén de versiones dejando las versiones consumadas sin cambios.

Versiones Sombra

Las versiones tentativas, se denominan versiones sombra. Cuando una transacción se consuma se hace un nuevo mapa que reemplaza al anterior. Para restaurar los objetos el gestor de recuperación lee el mapa y utiliza su información para localizar los objetos en el archivo de versiones. El mapa debe estar siempre en un lugar bien conocido: un archivo separado, al comienzo del almacén de versiones.

28

Versiones Sombra

A -> P1B -> P2C -> P0”

Mapa al Inicio Mapa cuando T se consuma

A -> P0B -> P0´C -> P0”

100 200 300 80 220 278 242

p0 P0´ P0” p1 p2 p3 p4

Procesamiento de Transacciones - LDC Noticiasmcuriel/Cursos/EspecializacionTelematica/Proc... ·...

Documents

Transcript of Procesamiento de Transacciones - LDC Noticiasmcuriel/Cursos/EspecializacionTelematica/Proc... ·...