Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Transacciones y Concurrencias

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 10

REPUBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA EDUCACION UNIVERSITARIA,


CIENCIA Y TECNOLOGIA
UNIVERSIDAD POLITECNICA TERRITORIAL DEL ESTADO PORTUGUESA J.J
MONTILLA

Transacciones Y Concurrencias

Integrantes:
Castellanos Carlos 21.024.060
Duran Alirio 21.160.655
Escalona Alinger 21.022.119
Garcia Maritrini 21.160.740
Hernandez Juan 21.023.088
Manzanilla Daniela 21.160.654
Prof. Lennys Camargo
Seccin: 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:
Iniciamos la

Modificamos un

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

También podría gustarte