Jose Manuel Perez

Daniel Futrill
Prof. Ana Aguilera

1 Introduccin
2 Concepto de Transacciones
2.1 Propiedades de las transacciones
2.2 Condiciones de terminacin de una transaccin
2.3 Caracterizacin de transacciones
2.4 Transacciones y planificadores
2.5 Ejecucin concurrente de transacciones
2.5.1 Motivos para la ejecucin concurrente
2.5.2 Seriabilidad
2.5.3 Anomalas de Ejecucin
2.5.4 Control de concurrencia basado en lock (cerraduras)
2.6 Tipos de Transacciones
2.7 Estructura de transacciones
2.8 Aspectos relacionados al procesamiento de transacciones
3 Conceptos relacionados con el control de concurrencia
3.1 Administracin de locks
3.2 Deadlocks prevencin y deteccin
3.3 Tcnicas de cerraduras especializadas
3.4 Control de Concurrencia sin locking

Hasta este momento, las primitivas bsicas de acceso que se han considerado
son las consultas. Sin embargo, no se ha discutido qu pasa cuando, por
ejemplo, dos consultas tratan de actualizar el mismo elemento de datos, o si
ocurre una falla del sistema durante la ejecucin de una consulta. Dada la
naturaleza de una consulta, de lectura o actualizacin, a veces no se puede
simplemente reactivar la ejecucin de una consulta, puesto que algunos datos
pueden haber sido modificados antes de la falla. El no tomar en cuenta esos
factores puede conducir a que la informacin en la base de datos contenga
datos incorrectos.
El concepto fundamental aqu es la nocin de "ejecucin consistente" o
"procesamiento confiable" asociada con el concepto de una consulta. El
concepto de una transaccin es usado dentro del dominio de la base de datos
como una unidad bsica de cmputo consistente y confiable.

Una transaccin es una ejecucin de un programa de usuario, visto por el

DBMS como una serie de operaciones lecturas y escrituras, la cual accede a la
base de datos que es compartida por varios usuarios en forma simultnea. Es
una coleccin de acciones que hacen transformaciones de los estados de un
sistema preservando la consistencia del mismo.
Una base de datos est en un estado consistente si obedece todas las
restricciones de integridad definidas sobre ella. Los cambios de estado ocurren
debido a actualizaciones, inserciones, y supresiones de informacin. Por
supuesto, se quiere asegurar que la base de datos nunca entra en un estado de
inconsistencia. Sin embargo, durante la ejecucin de una transaccin, la base
de datos puede estar temporalmente en un estado inconsistente. El punto
importante aqu es asegurar que la base de datos regresa a un estado
consistente al fin de la ejecucin de una transaccin.

La Base de
Datos en
estado
consistente

Inicio de Transaccin
T1

La Base de Datos
temporalmente en un
estado inconsistente
durante la ejecucin de la
transaccin

Ejecucin de la
Transaccin T1

La Base de
Datos en
estado
consistente

Fin de Transaccin T1

Para fines de recuperacin el sistema necesita mantenerse al tanto de cuando

la transaccin se inicia, termina y se confirma o aborta, as el gestor de
recuperacin se mantiene al tanto de las siguientes operaciones:

 INICIO_DE_TRANSACCIN: marca el inicio de la ejecucin de la transaccin

LEER o ESCRIBIR: especifican operaciones de lectura o escritura de
elementos de la base de datos que se efectan como parte de una transaccin.
FIN_DE_TRANSACCIN: especifica que las operaciones de leer o escribir
han terminado y marca el lmite de la ejecucin de la transaccin. Sin embargo,
puede ser necesario verificar si los cambios introducidos por la transaccin se
pueden aplicar permanentemente a la base de datos (Confirmar) o si debe
abortarse porque viola el control de concurrencia o por alguna otra razn.
CONFIRMAR_TRANSACCIN: seala que la transaccin termin con xito y
que cualquier actualizacin ejecutada por ella se puede confirmar sin peligro en
la base de datos y no se cancelarn.
ABORTAR: indica que la transaccin termin sin xito y que cualquier cambio
o efecto que pueda ser aplicado a la base de datos debe ser cancelado.
Se hacen necesarios mecanismos de control de concurrencia y de recuperacin
para garantizar estos estados.

Diagrama de Transicin de estados para la

ejecucin de transacciones

Operaciones y Cuerpo de una Transaccin:

Begin transaction : inicio de la transaccin
Read a : lectura del objeto a
Write a : escritura del objeto a
Rollback : anulacin de la transaccin
Commit : fin de la transaccin

Begin transaction T
O1
O2
.
.
.
On
Commit T
Oi e conjunto de
operaciones

Propiedades de las transacciones:

Atomicidad: Se refiere al hecho de que una transaccin se trata como una

unidad de operacin. Por lo tanto, o todas las acciones de la transaccin se
realizan o ninguna de ellas se lleva a cabo. La atomicidad requiere que si una
transaccin se interrumpe por una falla, sus resultados parciales deben ser
deshechos. La actividad referente a preservar la atomicidad de transacciones
en presencia de abortos debido a errores de entrada, sobrecarga del sistema
o interbloqueos se le llama recuperacin de transacciones. La actividad de
asegurar la atomicidad en presencia de cadas del sistema se le llama
recuperacin de cadas.
Consistencia: La consistencia de una transaccin es simplemente su
correctitud. En otras palabras, una transaccin es un programa correcto que
lleva la base de datos de un estado consistente a otro con la misma
caracterstica. Debido a esto, las transacciones no violan las restricciones de
integridad de una base de datos.

Propiedades de las transacciones:

Aislamiento: Una transaccin en ejecucin no puede revelar sus resultados a

otras transacciones concurrentes antes de su commit. Ms an, si varias
transacciones se ejecutan concurrentemente, los resultados deben ser los
mismos que si ellas se hubieran ejecutado de manera secuencial
(seriabilidad).

Durabilidad: Es la propiedad de las transacciones que asegura que una vez

que una transaccin hace su commit, sus resultados son permanentes y no
pueden ser borrados de la base de datos. Por lo tanto, los DBMS aseguran
que los resultados de una transaccin sobrevivirn a fallas del sistema. Esta
propiedad motiva el aspecto de recuperacin de bases de datos, el cual trata
sobre como recuperar la base de datos a un estado consistente en donde
todas las acciones que han hecho un commit queden reflejadas.

Ejemplo: transferencia de fondos

1. read(A)
2. A := A 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)
Transaccin para
transferir $50 de la
cuenta A a la cuenta B

Consistencia: la suma de A y B no debe

cambiar por la ejecucin de la transaccin
Atomicidad: si la transaccin falla entre los
pasos 3 y 6, el sistema debe asegurar que los
cambios no se reflejen en la BD
Aislamiento: si entre los pasos 3 y 6 se le
permite a otra transaccin acceder a los datos
parcialmente modificados, ver un estado
inconsistente de la BD
Durabilidad: una vez que el usuario ha sido
notificado que la transaccin se realiz, los
cambios deben persistir a pesar de fallas

Condiciones de terminacin de una transaccin:

Una transaccin siempre termina, aun en la presencia de fallas. Si una
transaccin termina de manera exitosa se dice que la transaccin hace un
commit. Si la transaccin se detiene sin terminar su tarea, se dice que la
transaccin aborta. Cuando la transaccin es abortada, su ejecucin es
detenida y todas sus acciones ejecutadas hasta el momento son deshechas
(undone) regresando a la base de datos al estado antes de su ejecucin. A esta
operacin tambin se le conoce como rollback.

Caracterizacin de transacciones:
Las acciones de lectura y escritura se utilizan como base para caracterizar a las
transacciones. Los elementos de datos que lee una transaccin se dice que
constituyen el conjunto de lectura (RS). Similarmente, los elementos de
datos que una transaccin escribe se les denomina el conjunto de escritura
(WS). Note que los conjuntos de lectura y escritura no tienen que ser
necesariamente disjuntos. La unin de ambos conjuntos se le conoce como el
conjunto base de la transaccin (BS = RS U WS).
Ejemplo: Los conjuntos de lectura y escritura de la siguiente transaccin:
RS[Reservacin] = { FLIGHT.STSOLD, FLIGHT.CAP }
WS[Reservacin] = { FLIGHT.STSOLD, FC.FNO, FC.DATE, FC.NAME,
FC.SPECIAL }

Transacciones y Planificaciones (Schedules):

Hasta ahora conocemos que una transaccin es vista por el DBMS como una
serie, o lista, de acciones las cuales ejecutan operaciones de lectura y
escritura en elementos de la Base de Datos. Tambin sabemos que una
transaccin debe especificar su accin de finalizacin como commit (Finaliz
exitosamente) o abort (finaliz pero deshizo todas las acciones llevadas a
cabo).
Ahora, una planificacin, es una lista de acciones (lecturas, escrituras, abortos o
commit) de un conjunto de transacciones, y el orden que el cual dos acciones
de una transaccin T aparecen en una Planificacin debe ser el mismo orden
en el cual aparecen en T. En otras palabras una Planificacin representa una
secuencia de ejecucin actual o potencial el cual describe las acciones de las
transacciones as como son vistas por el DBMS.

Ejemplo de una Planificacin :

T1

T2

R(A)

Una Planificacin completa es aquella que

contiene todas las acciones de cada transaccin
que aparecen en el.

W(A)
R(B)
W(B)
Commit
R(C)
W(C)
Commit

Si las acciones de diferentes transacciones no

estn entrelazadas (las acciones son ejecutadas
de inicio a fin, una por una) la llamamos una
Planificacin Serial o Secuencial.

Ejecucin concurrente de transacciones

Conociendo el concepto de planificacin, ahora se puede describir
ejecuciones entrelazadas o interleaved de transacciones.
El DBMS entrelaza las acciones de diferentes transacciones para mejor el
rendimiento, en trminos de incrementar el promedio de transacciones
completadas en un determinado tiempo o mejorar los tiempos de respuestas
de las transacciones cortas.

Motivos para ejecucin concurrente:

La Planificacin mostrada en la siguiente figura muestra una ejecucin
entrelazada de dos transacciones.

Asegurar el aislamiento de las

transacciones mientras se permite
la ejecucin concurrente es difcil,
pero es necesario, hay que mejorar
el rendimiento.

Seriabilidad:
Cualquier ejecucin de un conjunto de transacciones es correcta si es libre
de interferencias.
Una planificacin Serializable es una equivalencia de alguna de las
ejecuciones seriales de las transacciones. Si cada transaccin preserva
consistencia, cada planificacin serializable preserva consistencia.

Anomalas que surgen con la ejecucin entrelazadas

La ejecucin entrelazadas de transacciones sin control puede
resultar en una base de datos inconsistente.
Problemas de:
Prdida de la actualizacin:
Diferentes ejecuciones entrelazadas pueden producir
valores finales diferentes.
Lectura inconsistente:
Existen ejecuciones entrelazadas que violan RI.
Lectura irreproducible:
Existen ejecuciones entrelazadas donde el valor
desplegado no es el mismo.
-Sobreescribiendo datos inconsistente
-Existe una transaccin que sobreescribe un valor, el cual haba sido modificado
por otra transaccin mientras esta estaba corriendo.

Conflictos de WR:

T1:
T2:

R(A), W(A),

R(A), W(A), C

R(B), W(B), Abort

Conflictos de WR:

T1:
T2:

R(A),

R(A), W(A), C

R(A), W(A), C

Conflictos de WW:

T1:
T2:

W(A),

W(A), W(B), C

W(B), C

Planificacin Invocando a transacciones Abortadas

Una transaccin siempre termina, aun en la
presencia de fallas. Si una transaccin termina de
manera exitosa se dice que la transaccin hace un
compromiso. Si la transaccin se detiene sin
terminar su tarea, se dice que la transaccin
aborta.
Cuando la transaccin es abortada, puede ser por
distintas razones relacionadas con la naturaleza de
la transaccin misma, o por conflicto con otras
transacciones o por fallo de un proceso o
computador, entonces su ejecucin es detenida y
todas las acciones ejecutadas hasta el momento
son deshechas regresando a la base de datos al
estado antes de su ejecucin. A esta operacin
tambin se la conoce como rollback.

Control de Concurrencia Basado en Lock:

En los algoritmos basados en candados, las transacciones indican sus intenciones
solicitando candados al despachador (llamado el administrador de candados) Los
candados son de lectura , tambin llamados compartidos, o de escritura , tambin
llamados exclusivos.
En sistemas basados en candados, el despachador es un administrador de
candados . El administrador de transacciones le pasa al administrador de
candados la operacin sobre la base de datos (lectura o escritura) e informacin
asociada, como por ejemplo el elemento de datos que es accedido y el
identificador de la transaccin que est enviando la operacin a la base de datos.

Tipos de Transacciones:
Las transacciones pueden pertenecer a varias clases. Las transacciones pueden
ser agrupadas a lo largo de las siguientes dimensiones:
reas de aplicacin. En primer lugar, las transacciones se pueden ejecutar en
aplicaciones no distribuidas. Las transacciones que operan en datos
distribuidos se les conoce como transacciones distribuidas.
Tiempo de duracin. Tomando en cuenta el tiempo que transcurre desde que se
inicia una transaccin hasta que se realiza un commit o se aborta, las
transacciones pueden ser de tipo batch o en lnea.
Estructura. Considerando la estructura que puede tener una transaccin se
examinan dos aspectos: si una transaccin puede contener a su vez
subtransacciones o el orden de las acciones de lectura y escritura dentro de
una transaccin

Estructuras de las Transacciones:

Las transacciones planas consisten de una secuencia de operaciones primitivas
encerradas entre las palabras clave begin y end. Por ejemplo,
Begin_transaction Reservacin
...
end.
En las transacciones anidadas las operaciones de una transaccin pueden ser as
mismo transacciones. Por ejemplo,
Begin_transaction Reservacin
...
Begin_transaction Vuelo
...
end. {Vuelo}
...
Begin_transaction Hotel
...
end.
...
end.

Aspectos relacionados al procesamiento de transacciones:

Modelo de estructura de transacciones: considerar si las transacciones son

planas o pueden estar anidadas.

Consistencia de la base de datos interna: Los algoritmos de control de

datos semntico tienen que satisfacer siempre las restricciones de integridad
cuando una transaccin pretende hacer un commit.

Algoritmos de control de concurrencia: Los algoritmos de control de

concurrencia deben sincronizar la ejecucin de transacciones concurrentes
bajo el criterio de correctitud. La consistencia entre transacciones se garantiza
mediante el aislamiento de las mismas.

Protocolos de control de rplicas: El control de rplicas se refiere a cmo

garantizar la consistencia mutua de datos replicados. Por ejemplo se puede
seguir la estrategia read-one-write-all (ROWA).

Conceptos relacionados con el control de concurrencia:

Planificacin serial: recordamos el
concepto antes visto; para cada transaccin
T participando en el Planificacin, todas las
operaciones de T se ejecutan
consecutivamente en la Planificacin; sino, T
es no serial.
Planificaciones Equivalentes: Para que
dos Planificaciones sean equivalentes, las
operaciones aplicadas a cada dato afectado
por las planificaciones deben ser aplicadas
en ambas planificaciones en el mismo orden
Planificacin serializable: equivalente a
alguna Planificacin serial

T1
read (A)
A := A-50
write (A)

T2

read (A);
temp := A * 0.1
A := A temp
write (A)
read (B)
B := B+50
write (B)
Commit

read (B)
B:=B+temp
write (B)
Commit

Plan Serializable

Conceptos relacionados con el control de concurrencia:

Serializabilidad:
Un plan serializable implica que el plan es correcto
Deja la base de datos en un estado consistente
El intercalamiento es apropiado y resultar en un estado como si las
transacciones fueran ejecutadas secuencialmente, pero ser eficiente debido a la
ejecucin concurrente.
La serializabilidad es difcil de verificar
El intercalamiento de las operaciones ocurre en el sistema operativo a travs de
un planificador
Difcil determinar de antemano como las operaciones sern intercaladas
Enfoque prctico:
Protocolos asegurando la serializabilidad a travs del uso de Candados (locks)

Propsito del Control de Concurrencia:

En general, reforzar el aislamiento (a travs de la exclusin mutua) entre
transacciones conflictivas.
En particular, evitar los problemas de:
Actualizacin perdida
Actualizacin temporal
Suma incorrecta

Problema de la Actualizacin Perdida:

Ocurre cuando dos transacciones que acceden los mismos datos tienen sus
operaciones intercaladas de forma que hacen que el valor de un dato sea
incorrecto.
T1
read_item (X)
X := X-N

T2
read_item (X)
X := X+M

write_item (X)
read_item (Y)
Y:= Y+N
write_item (Y)
Commit

write_item (X)
Commit

X tiene un valor incorrecto

porque la actualizacin de T1 se
pierde

Problema de la de la actualizacin temporal:

Ocurre cuando una transaccin actualiza un dato y despus falla. El dato
actualizado es accedido por otra transaccin antes de cambiar su valor al
original.
T1
read_item (X)
X := X-N
write_item (X)

T2

read_item (X)
X := X+M
write_item (X)
Commit
read_item (Y)
Abort

T1 falla y debe regresar el valor

modificado de X al original; T2
ley temporalmente el valor
incorrecto de X.

Problema de la suma incorrecta:

Si una transaccin est calculando una funcin matemtica sobre un conjunto
de tuplas mientras que otras transacciones estn actualizndolas, el
resultado puede ser incorrecto.
T1

T3
sum :=0
read_item(A)
sum := sum+A

read_item (X)
X := X-N
write_item (X)

read_item(Y)
Y := Y+N
write_item(Y)
Commit

read_item(X)
sum:=sum+X
read_item(Y)
sum :=sum+Y
Commit

T3 lee X despus de sustraer N y

lee Y antes de sumar N: el
resultado es incorrecto

Protocolos basados en candados (Locks):

Es un conjunto de reglas seguidas por todas las transacciones para solicitar y
liberar candados. Un candado es un mecanismo de control de acceso
concurrente a un dato
Los datos pueden tener candados en dos modos:
Modo exclusivo (X). El dato puede ser ledo y escrito. Un candado en este
modo se solicita con la instruccin lock-X
Modo compartido (S). El dato solo puede ser ledo. Un candado en este
modo se solicita con la instruccin lock-S.
Las transacciones indican sus intenciones solicitando candados al despachador
(llamado el administrador de candados). La transaccin puede proceder
solo despus de que una solicitud es otorgada.

Protocolos basados en candados:

Como se aprecia en la tabla siguiente, los candados de lectura presentan
conflictos con los candados de escritura, dado que las operaciones de
lectura y escritura son incompatibles.
Un candado es otorgado si el candado
solicitado es compatible con otros candados
previamente otorgados.
Se pueden tener varios candados
compartidos sobre un dato, pero slo un
candado exclusivo.
Si un candado no puede ser concedido, la
transaccin que lo solicita debe esperar a
que todos los candados incompatibles sean
El poner candados no es suficiente liberados.
para garantizar serializabilidad

Protocolo de candado en dos fases (2PL):

Asegura planificaciones serializables.
Fase 1: Crecimiento
Una transaccin puede solicitar/obtener candados
Una transaccin no puede liberar candados
Fase 2: reduccin
Una transaccin puede liberar candados
Una transaccin no puede obtener candados
En los candados de dos fases una transaccin le pone un candado a un objeto
antes de usarlo. Cuando un objeto es bloqueado con un candado por otra
transaccin, la transaccin solicitante debe esperar. Cuando una
transaccin libera un candado, ya no puede solicitar ms candados.

Protocolo de candado en dos fases (2PL):

Una transaccin que utiliza candados de dos fases se comporta como en la
siguiente figura. En la primera fase solicita y adquiere todos los candados
sobre los elementos que va a utilizar y en la segunda fase libera los
candados obtenidos uno por uno.

Protocolo de candado en dos fases (2PL):

La importancia de los candados de dos fases es que se ha demostrado de
manera terica que todos los planificadores generados por algoritmos de
control de concurrencia que obedecen a los candados de dos fases son
serializables.
Abortos en Cascada: Puede suceder si una transaccin aborta despus de
liberar un candado, otras transacciones que hayan accedido el mismo
elemento de datos aborten tambin.
Para evitar lo anterior, los despachadores para candados de dos fases
implementan lo que se conoce como los candados estrictos de dos fases
en los cuales se liberan todos los candados juntos cuando la transaccin
termina (con commit o aborta).
Ver la siguiente figura.

Protocolo de candado en dos fases (2PL):

Problemas de los protocolos basados en candados: abrazo mortal:

Abrazo mortal: dos transacciones esperan mutuamente a que la otra libere un
candado.
Prevencin: una transaccin pone un candado a todos los datos a los que se
refiere antes de comenzar su ejecucin.
Evitar: si una transaccin intenta crear un ciclo, entonces se echa para atrs
(roll back) esa transaccin.

Problemas de los protocolos basados en candados: inanicin:

Ocurre cuando una transaccin en particular consistentemente espera o es
reinicializada y nunca tiene la posibilidad de seguir adelante.
Esta limitacin es caracterstica de todos los mecanismos de planificacin
basados en prioridades (estampillas de tiempo).

Tecnicas de cerraduras Especializadas

Lecturas fantasma
Una transaccin vuelve a ejecutar una consulta, devolviendo un conjunto de filas
que satisfacen una condicin de bsqueda y encuentra que otras filas que
satisfacen la condicin que han sido insertadas por otra transaccin cursada.

Control de Concurrencia sin locking

Control de concurrencia optimista
Los algoritmos de control de concurrencia discutidos antes son por naturaleza
pesimistas. En otras palabras, ellos asumen que los conflictos entre
transacciones son muy frecuentes y no permiten el acceso a un dato si existe una
transaccin conflictiva que acceda al mismo dato. As, la ejecucin de cualquier
operacin de una transaccin sigue la secuencia de fases: validacin (V), lectura
(R), cmputo (C) y escritura (W). Los algoritmos optimistas, por otra parte,
retrasan la fase de validacin justo antes de la fase de escritura. De esta manera,
una operacin sometida a un despachador optimista nunca es retrasada.

 Database Management, Ramakrishnan Gehrke

Sistema de bases de datos, Elmasri Navathe
http://www.utm.mx/~caff/perso/index.html
http://www.cs.princeton.edu/courses/archive/spr00/cs425/slides/
https://dpt-info.u-strasbg.fr/doc/oracle/server.102/b14220/transact.htm
www.cs.ust.hk/~dimitris
codex.cs.yale.edu/avi/db-book
http://www.cs.cinvestav.mx/SC/prof_personal/adiaz/Disdb/Cap_5.html
http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/MonogSO/
TRANS02.htm
http://es.tldp.org/Postgresql-es/web/navegable/user/x3589.html