REPUBLICA BOLIVARIANA DE VENEZUELAMINISTERIO DEL PODER POPULAR PARA LA EDUCACION UNIVERSITARIA, CIENCIA Y TECNOLOGIAUNIVERSIDAD POLITECNICA TERRITORIAL DEL ESTADO PORTUGUESA J.J MONTILLA

(Transacciones Y Concurrencias)

Integrantes:

Castellanos Carlos 21.024.060Duran Alirio 21.160.655Escalona Alinger 21.022.119Garcia Maritrini 21.160.740Hernandez Juan 21.023.088Manzanilla Daniela 21.160.654

Prof. Lennys CamargoSeccin: 808 Ing. Informatica

Guanare, Julio de 2015

Concurrencia:

El control de concurrencia trata con los problemas de aislamiento y consistencia del procesamiento de transacciones. El control de concurrencia distribuido de una DDBMS asegura que la consistencia de la base de datos se mantiene en un ambiente distribuido multiusuario. Si las transacciones son internamente consistentes, la manera ms simple de lograr este objetivo es ejecutar cada transaccin sola, una despus de otra. Sin embargo, esto puede afectar grandemente el desempeo de un DDBMS dado que el nivel de concurrencia se reduce al mnimo.

El nivel de concurrencia, el nmero de transacciones activas, es probablemente el parmetro ms importante en sistemas distribuidos. Por lo tanto, los mecanismos de control de concurrencia buscan encontrar un balance entre el mantenimiento de la consistencia de la base de datos y el mantenimiento de un alto nivel de concurrencia.

Si no se hace un adecuado control de concurrencia, se pueden presentar dos anomalas. En primer lugar, se pueden perder actualizaciones provocando que los efectos de algunas transacciones no se reflejen en la base de datos. En segundo trmino, pueden presentarse recuperaciones de informacin inconsistentes.

Correctitud:

Una ejecucin concurrente de un conjunto de transacciones (t1, t2, ..., tn) es correcta si y slo si existe una secuencia de dichas transacciones que ejecutadas serialmente daran los mismos resultados. Se dice entonces que si el concepto de correctitud se cumple el conjunto de transacciones es serializable. Para examinar la correctitud de la ejecucin concurrente de un conjunto de transacciones hay que definir la precedencia existente entre las mismas.

Entonces se tiene que una transaccin A precede a una transaccin B si la transaccin B ve un dato que la transaccin A modific o si la transaccin A ve un dato que la transaccin B modificar. En el ejemplo anterior se tiene que la ejecucin concurrente de A y B no es correcta ya que A precede a B porque A ve un dato que B modificar y al mismo tiempo B precede a A ya que B ve un dato que A modificar. Entonces no se puede establecer una serializacin posible entre ambas transacciones. Si ambas transacciones se ejecutan concurrentemente se obtiene que el valor de F es 8, ya que:

Transaccin A: 4 + 1 = 5

Transaccin B: 4 * 2 = 8

Este resultado no se corresponde con ninguno de los obtenidos por la ejecucin serial de ambas transacciones y se dice que en este caso se presenta el problema de la actualizacin perdida, ya que la actualizacin que hace A se pierde porque B la sobrescribe. Es claro, entonces, que en un ambiente multiusuario es necesario algn mecanismo de control de concurrencia con el fin de evitar estos problemas y otros. El problema esencial aqu es que ambas transacciones A y B actualizan RF sobre la base del valor inicial del campo y ninguna ve la salida de la otra transaccin. Para prevenir esta situacin hay tres cosas bsicas que puede hacer un mecanismo de control de concurrencia:

1. Puede impedir el FIND de B en el tiempo t2 en base al hecho de que la transaccin A ya ha direccionado al registro R y puede ser que vaya a actualizarlo posteriormente.

2. Puede impedir la actualizacin de A en el tiempo t3 en base al hecho de que B ya ha direccionado al registro R y B ya ha visto el valor de R antes de la actualizacin.

3. Puede impedir la actualizacin de B en el tiempo t4 en base al hecho de que A ya ha actualizado a R y entonces la actualizacin de B va a estar basada en un valor obsoleto de R

Conflictos:

Actualizacin perdida:

Este problema puede presentarse si dos transacciones concurrentes actualizan una misma tupla, y la segunda que se realiza al final ,no toma en cuenta el efecto de la primera.

Recuperaciones inconsistentes:

Ocurre cuando una transaccin hace un anlisis contable o estadstico, sobre una tupla que est siendo actualizada por otra transaccin.

Serializabilidad

La serializacin es el criterio de lo correcto, para el control de la concurrencia. Un conjunto entrelazado de transacciones es correcto si es serializable. Es decir si produce el mismo resultado mediante la ejecucin en serie de las mismas transacciones. Dado un conjunto de transacciones entrelazadas, cualquier ejecucin de esas transacciones se dice que es una calendarizacin (scheduling)

Esta es la ejecucin de esta aseveracin:

1. - Las transacciones individuales son tomadas como correctas es decir, se da por hecho que transforman un estado correcto de la base de datos en otro estado correcto.

2. - Por lo tanto tambin es correcta la ejecucin de una transaccin a la vez en cualquier orden serial y se dice en cualquier orden serial debido a que las transacciones individuales son consideradas independientes entre s.

3. - Por lo tanto una ejecucin intercalada es correcta cuando equivale a una ejecucin serial, es decir cuando es seriable.

Formas de planificar la serilizabilidad

Por Conflicto

Eliminar conflictos entre dos o ms transacciones

Operaciones sobre los mismos datos en ms de una transaccin

Tipos de Operaciones:

T1: lectura y T2: lectura

No hay conflicto

T1: lectura y T2: escritura T1: escritura y T2: lectura

Conflicto: hay que respetar el orden

T1: escritura y T2: escritura

Conflicto: el orden afecta al valor final de la BD

Se dice que hay conflicto cuando se consideran operaciones sobre los mismos datos en dos transacciones diferentes

Un plan de ejecucin se puede transformar en otro cambiando de orden las instrucciones y manteniendo la serializabilidad

Todos estos planes son equivalentes al plan secuencial.

Por Vista

Se basa en definir una regla de equivalencia menos estricta que la de conflicto.

Pero basndose solo en las operaciones de lectura y escritura.

Se puede considerar como un refinamiento de la equivalencia por conflicto.

Algoritmo Optimista

Permite que las transacciones procedan como si no hubiese posibilidad de conflicto con otras transacciones, hasta que el cliente complete su tarea y solicite un EndTransaction (Commit). Cuando aparece un conflicto se abortar la transaccin.

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 vlidos, de no serlos, se aborta la transaccin.

A toda transaccin se le asigna un identificador (orden secuencial ascendente) para llevar una sucesin de transacciones en el tiempo.

Cada transaccin cumple tres fases:

Trabajo: Todos los reads se ejecutan inmediatamente sobre la ltima versin comprometida del dato. Los writes crean versiones tentativas. Se mantiene un conjunto de lectura (datos ledos) y un conjunto de escritura (versiones tentativas de los datos).

Validacin: Ante la solicitud de un commit, se valida si la transaccin realiz operaciones conflictivas con otras transacciones.

Escritura: Si la transaccin es validada, todos los cambios hechos sobre los espacios privados son actualizados en las versiones originales.

Desventajas:

Hay posibilidad se inanicin: una transaccin puede abortar indefinidas veces y no se contempla mecanismo para evitar esto.

Tambin es importante saber que este algoritmo no servira para nada en sistema con carga alta.

Algoritmo de Locking Bloqueo

Nivel de granularidad del bloqueo: tiene que ver con el tamao del objeto o dato que esta bloqueado

A mayor granulidad (mayor fineza del grano), ms pequeo es el tamao del objeto

El nivel de bloqueo es directamente proporcional al grado de paralelismo y concurrencia, pero tambin es directamente proporcional al grado de complejidad de los sistemas

Mientras mayor sea la fineza del grano, mejor sera el grado de paralelismo/concurrencia, pero mayor ser la complejidad del sistema

El bloqueo puede ser a nivel de tem, pagina, archivo, base de datos, (donde item representa el grano ms fino y base de datos corresponde al grano mas grueso)

Consiste en que cada vez que un proceso necesita leer o escribir en un objeto como parte de una transaccin, el objeto se bloquea hasta que la transaccin culmine exitosamente (commit) y cualquier otra transaccin que desee hacer alguna operacin sobre dicho objeto tendr que esperar que el 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 por cada maquina

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

Otra mejora: promocion 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 otorgara el lock de escritura despues de todas las demas 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

El Algoritmo de bloqueo resuelve:

Recuperaciones inconsistentes: No hay posibilidad de que dos operaciones conflictivas se ejecuten concurrentemente

Perdidas de Actualizaciones: Si dos transacciones leen el mismo dato y luego lo modifican, la segunda espera (ya sea por promocion o por no otorgamiento)

El problema de algoritmo de locking es que puede ocasionar deadlocks y abortos en cascada, por lo que se han propuesto algunas variaciones para evitar tales problemas

Algoritmo de Bloque de Dos Fases "Obtencion" y "Liberacin"

Durante la fase de "obtencion", la transaccion trata de obtener todos los locks que necesite. Si no posible obtener alguno, entonces espera.

La segunda fase comienza cuando la transaccion libera alguno de los locks, a partir de ese momento no podra solicitar ningun otro lock (si lo hace, sera abortada).

Desventaja: si una transaccin en la fase de liberacin habia desbloqueado algunos objetos y los mismos habian sido accedidos por otras transacciones antes de que la primera hiciera commit, entonces las demas transacciones deberian abortar (esto es abortos en cascada).

Algoritmo de Bloqueo de Dos Fases Estrictas

La fase de "liberacion" se realiza solo cuando la transaccin hace commit, la mejora: evita los abortos en cascada.

Desventajas:

Al nivel de paralelismo se degrada, permanece la posibilidad de deadlock y aun representa un alto costo de mantenimiento.

Grafica comparativa entre el bloque de dos fases y el bloqueo de dos fases estrictas

Interbloqueo:

Un interbloqueo se produce cuando dos o ms tareas se bloquean entre s permanentemente teniendo cada tarea un bloqueo en un recurso que las otras tareas intentan bloquear.

Un interbloqueo es una condicin que se puede dar en cualquier sistema con varios subprocesos, no slo en un sistema de administracin de bases de datos relacionales, y puede producirse para recursos distintos a los bloqueos en objetos de base de datos

Por ejemplo:

La transaccin A tiene un bloqueo compartido de la fila 1.

La transaccin B tiene un bloqueo compartido de la fila 2.

La transaccin A ahora solicita un bloqueo exclusivo de la fila 2 y se bloquea hasta que la transaccin B finalice y libere el bloqueo compartido que tiene de la fila 2.

La transaccin B ahora solicita un bloqueo exclusivo de la fila 1 y se bloquea hasta que la transaccin A finalice y libere el bloqueo compartido que tiene de la fila 1.

Condiciones que producen la aparicin de un interbloqueo:

1. Condicin de exclusin mutua: Cada recurso est asignado a un nico proceso o est disponible.

2. Condicin de posesin y espera: Los procesos que tienen, en un momento dado, recursos asignados con anterioridad, pueden solicitar nuevos recursos.

3. Condicin de no apropiacin: Los recursos otorgados con anterioridad no pueden ser forzados a dejar un proceso: El proceso que los posee debe liberarlos en forma explcita.

4. Condicin de espera circular: Debe existir una cadena circular de dos o ms procesos, cada uno de los cuales espera un recurso posedo por el siguiente miembro de la cadena.

ejemplo de interbloqueo:

(Modificamos un registro) (Iniciamos la transaccin)

(Otra transaccin trata de Modificamos el mismo registro, pero queda bloqueado, hasta que la otra transaccin finalice con un commit.)

(Ahora si se ejecuta transaccin)

(Finalizamos la transaccin con el commit)