Transacciones y Control de 

Concurrencias
Por: Cordoba, Benjamin;
Díaz, David;
Rojas, Rafael;
Zamorano, Corina;
Zou, Raymond.
 Introducción

La meta de las transacciones es asegurar que todos los objetos gestionados por un
servidor permanecen en un estado consistente cuando dichos objetos son accedidos por
múltiples transacciones y en presencia de caídas del servidor.
Una transacción viene especificada desde un cliente como un conjunto de operaciones
sobre los objetos que se realizaran como una unidad indivisible por los servidores que
gestionan dichos objetos. Los servidores deben garantizar que se realiza completamente
la transacción y que los resultados se almacenan en una memoria permanente o, en el
caso de una o más caídas , sus efectos se eliminan completamente.
En la siguiente presentación discutiremos temas relacionados con transacciones que
implican varios servidores, conoceremos los métodos de control de concurrencia para
transacciones, transacciones anidadas.
 Transacciones

Una transacción es un conjunto de operaciones DML (INSERT, UPDATE, DELETE) que se

ejecutan como un único bloque, es decir, si falla una operación fallan todas.
Si una transacción tiene éxito, todas las modificaciones de los datos realizadas durante la
transacción se confirman y se convierten en una parte permanente de la base de datos.
Si una transacción encuentra errores y debe cancelarse o revertirse, se borran todas la
modificaciones de los datos.
El ejemplo clásico de una transacción es una transferencia bancaria, en la que quitamos
saldo a una cuenta y lo añadimos a otra. Si no somos capaces de abonar el dinero en la
cuenta destino, no debemos quitarlo de la cuenta origen.
 Concurrencia

La concurrencia se produce cuando varios procesos se ejecutan simultáneamente, lo que

conlleva habitualmente el acceso a los mismos datos. Por tanto, hay que utilizar
herramientas que eviten la inconsistencia de los datos.
Podemos prevenir al modificación de ciertas tablas, bloqueando el acceso a éstas en
ciertos momentos. De esta forma las tablas bloqueadas no aceptarán accesos de lectura
o escritura de otras sesiones.
 Operaciones atómicas en el servidor
Son las operaciones que están libres de interferencia de operaciones concurrentes que se
están realizando en otros hilos.
Los métodos de los objetos deben estar diseñados para funcionar en un contexto multi-hilo, si
no están diseñados para su utilización en un programa multi-hilo, es posible que las acciones
de dos o más ejecuciones concurrentes del método puedan entremezclarse arbitrariamente y
tener efectos extraños en las variables de instancia de los objetos.
El uso de la palabra synchronized (sincronizado), que puede ser aplicado a los métodos en
Java para asegurar que sólo se puede acceder a un objeto un hilo cada vez.

public synchronized void deposita(int cantidad) throws RemoteException {

// añade cantidad al balance de cuenta.

}
 Mejora de la colaboración del cliente mediante
sincronización de las operaciones del servidor

Los clientes pueden utilizar un servido como un medio de compartir algunos recursos.
Esto se consigue por algunos clientes utilizando operaciones para actualizar los objetos
del servidor y otros utilizando operaciones para acceder a ellos.
Los métodos wait y notify permiten que los hilos se comuniquen con los otros de manera
que resuelva los problemas anteriores. Deben utilizarse dentro de los métodos
sincronizados de un objeto.
Un hilo llama a wait en un objeto para suspenderse él mismo y permitir a otro hilo
ejecutar un método de ese objeto.
Un hilo llama a notify para informar que cualquier hilo que esté esperando en el objeto
que ha cambiado alguno de sus datos
 Modelo de Fallos para
transacciones
Lampson propuso un modelo de fallos para transacciones distribuidas que considera los
fallos en: Discos, Servidores y Comunicación. En el modelo se intenta que los algoritmos
trabajen correctamente en presencia de fallos predecibles, pero no se hacen
consideraciones cuando ocurre un desastre. El modelo establece lo siguiente:
Las escrituras pueden fallar (no se escribe nada, o se escribe un valor incorrecto)
Los servidores pueden fallar ocasionalmente. Cuando el servidor se reemplaza por otro, el
nuevo proceso debe realizar un proceso de recuperación utilizando la memoria
permanente y la información que le puedan suministrar otros procesos.
Puede existir un retardo arbitrario antes de que llegue un mensaje. Un mensaje se puede
perder, duplicar o modificar. Se pueden detectar mensajes modificados. Los mensajes
falsificados y corruptos que no se puedan detectar se les considera como desastres.
 Solicitudes atómicas

Aislamiento: cada transacción debe ser realizada sin interferencia de otras

transacciones, en otras palabras, los efectos intermedios de una transacción no debe
ser visibles para las demás.
Todo o Nada: Una transacción o finaliza correctamente, y los efectos de todas sus
operaciones son registrados en los objetos, o (si falla) no tienen ningún efecto. Este
efecto tiene dos aspectos en si mismo:
Atomicidad de fallo: los efectos son atómicos aun en el caso de ruptura de
servidor.
Durabilidad: después que una transacción ha finalizado con éxito, todos sus
efectos son guardados en el almacenamiento permanente.
 Propiedades ACID de las
Transacciones
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) efecto equivalente a una ejecución secuencial.
Durabilidad (Durability) los efectos de una transacción consumada no se pierden,
perduran.
Transacciones Anidadas
Actualizaciones Perdidas
Recuperaciones Inconsistentes
Equivalencia Secuencial
Equivalencia Secuencial II
Operaciones Conflictivas
Solapamientos en Transacciones
Recuperabilidad de Transacciones
Abortadas
 Lecturas Sucias
Lecturas sucias El problema de leer un dato intermedio desde un
cliente, de una transacción en curso concurrentemente sobre el mismo
objeto. Si esta segunda abortara (imaginemos un depósito), la lectura de la
primera sería falsa y podría conducir a un error (imaginemos una extracción
o consulta de saldo)
 Recuperabilidad de transacciones
abortadas
Recuperación de la transacción Para evitar el efecto anterior, toda
transacción que utilice algún dato intermedio dependiente de una
transacción no finalizada debiera ESPERAR antes de darse por finalizada.

Abortos en cascada La consecuencia inmediata de lo anterior es que

pueden generarse abortos en cascada por “fallas” en transacciones de las
que dependan muchas otras. Evitar esto implica MAYOR demora, evitando
la lectura de datos de objetos con transacciones no terminadas.
 Escrituras Prematuras
Escrituras prematuras Si tenemos dos operaciones concurrentes de
escritura (supongamos sumar 10% a una cuenta), al abortar una de ellas
y tratar de recuperar el estado previo de la cuenta puede llevar a errores.
Esto se debe a una “escritura prematura”. Para evitarlo las escrituras
deben demorarse hasta completarse todas las demás escrituras
pendientes sobre el mismo objeto.
Recuperabilidad de transacciones
abortadas
Ejecuciones estrictas de las transacciones Mayor seguridad,
menor eficiencia.

Versiones provisionales Son los valores transitorios de un

objeto, mientras la transacción que opera sobre él no está
terminada. Deben mantenerse para poder recuperarse de fallos.
Bloqueos Exclusivos

Evitan que transacciones simultáneas tengan acceso a un recurso.

Al utilizar un bloqueo exclusivo, el resto de las transacciones no pueden
modificar los datos; las operaciones de lectura sólo se pueden realizar
si se utiliza la sugerencia NOLOCK o el nivel de aislamiento de lectura
no confirmada.
Bloqueos Exclusivos
 Bloqueo Compartido

Los bloqueos compartidos permiten que varias transacciones simultáneas

lean (SELECT) un recurso en situaciones de control de simultaneidad
pesimista.

Ninguna otra transacción podrá modificar los datos mientras el bloqueo

compartido exista en el recurso.

Los bloqueos compartidos en un recurso se liberan tan pronto como

finaliza la operación de lectura, a menos que se haya establecido el nivel
de aislamiento de la transacción
 Bloqueo de Dos Fases (2PL)

Utiliza bloqueos de lectura y escritura para prevenir conflictos entre

operaciones.
Fase de crecimiento. Una transacción puede obtener bloqueos pero no
puede liberarlos.
Fase de decrecimiento. Una transacción puede liberar bloqueos pero no
puede obtener ninguno nuevo.

El protocolo de bloqueo de dos fase no asegura la ausencia de interbloqueos.

 Bloqueo de Dos Fases (2PL)

 Si el objeto no estaba ya bloqueado, es bloqueado y empieza la

transacción.
 Si el objeto tiene activado un bloqueo conflictivo con otra transacción, la
transacción debe esperar hasta que esté desbloqueado.
 Si el objeto tiene activado un bloqueo no conflictivo de otra transacción, se
comparte el bloqueo y comienza la operación.
 Si el objeto ya ha sido bloqueado en la misma transacción, el bloqueo será
promovido si es necesario y comienza la operación.
 Cuando la transacción se consuma o aborta, el servidor desbloquea todos
los objetos implicados en la transacción.
 Bloqueo de Dos Fases Estricto
Exige que además de que el bloqueo sea de dos fases, una transacción debe poseer
todos los bloqueos en modo exclusivo de manera que dicha transacción no
comprometida esté bloqueada en modo exclusivo hasta que la transacción lea el
dato.

Evita los retrocesos en cascada.

 Bloqueo Riguroso de Dos Fases

 Exige que se posean todos los bloqueos hasta que se complete la

transacción.

 Se puede comprobar fácilmente que con el bloqueo riguroso de dos fases se

pueden secuenciar las transacciones en el orden en que se comprometen.
 Implementación de Bloqueos

 Los bloqueos se deben concesionar a través del gestor de bloqueos.

 Cada bloqueo tiene el identificador del objeto bloqueado, el identificador

de la transacción que lo esta bloqueando y el tipo de bloqueo.

 Los métodos de bloqueos están sincronizados de modo que los hilos que
intentan adquirir o liberar un bloqueo no interfieran con el otro.
 Servicio de Control de Concurrencia
CORBA
 Define las interfaces que permiten que múltiples objetos distribuidos
cooperen con el  fin de proveer atomicidad.
 Estas interfaces habilitan a los objetos a realizar "commit" (acometer)
todas las transacciones o "rollback" (reversar) las mismas en presencia de
alguna falla. 
 Habilita a múltiples clientes para acceder de manera coordinada a los
recursos compartidos.
 El uso concurrente de los recursos es regulado con semáforos y cada
semáforo se asocia con un recurso y un cliente particular.
 Bloqueo Indefinido

Es un estado en el que cada miembro de un grupo de transacciones está

esperando por algún otro miembro para liberar un bloqueo.
Se puede utilizar un grafo espera por para representar las relaciones de espera
entre las transacciones actuales.
En este grafo, los nodos representan las transacciones y los arcos representan
las relaciones espera por entre transacciones.

Donde:
R1 asignado a A y espera
por R2
R2 asignada a B y espera
por R1
 Condiciones

Podemos asegurar que un conjunto de procesos ha llegado a un bloqueo

indefinido si se cumplen las siguientes condiciones:
1. Exclusión mutua. Cada recurso está asignado a un único proceso de
manera exclusiva.
2. Retener y esperar. Cada proceso retiene los recursos que ya le han sido
asignados mientras espera a adquirir el resto de recursos.
3. No expropiación. Los recursos concedidos a un proceso sólo pueden ser
liberados y devueltos al sistema como resultado de la acción voluntaria de
ese proceso: el sistema no puede obligarle a entregarlos.
4. Espera circular. Los procesos bloqueados indefinidamente forman una
cadena circular de modo que cada proceso retiene uno o más de los recursos
que son solicitados por el siguiente proceso de la cadena.
 Técnicas para Gestionar Bloqueos
Indefinidos
 Prevención de Bloqueos Indefinidos.
 Evitación de Bloqueos Indefinidos.
 Detección de Bloqueos Indefinidos.
 Temporizaciones de Bloqueos Indefinidos.
 Prevención de Bloqueos
Indefinidos
 El proceso debe tener asignado todos los recursos necesarios al inicio y
no liberarlos hasta que éste finalice.
 En otras palabras, los bloqueos indefinidos se previenen debido a que los
procesos en espera no retienen recursos.
 Surge el inconveniente si un recurso sólo se utiliza al final, estará
ocupado durante toda la ejecución, no permitiendo ser usado por otros
procesos.
 Evitación de Bloqueos Indefinidos

La evitación de bloqueos indefinidos no requiere la adquisición de todos los

recursos de una vez, la idea básica es conceder únicamente las peticiones
de recursos disponibles que no puedan dar lugar a un estado de bloqueo
indefinido.
Como aspecto negativo, la evitación de bloqueo indefinido requiere la pre-
reclamación de las necesidades de recursos y aumenta el consumo de
almacenamiento y computación en tiempo de ejecución.
 Detección de Bloqueos

Los bloqueos indefinidos pueden detectarse a través de los ciclos en el grafo

espera por. Una vez detectado un bloqueo indefinido, para romper el ciclo se
debe seleccionar una transacción para abortar.
Factores a considerar:
 Es mejor abortar transacciones que lleven poco tiempo en ejecución
 Es mejor abortar una transacción que haya hecho pocos cambios en la base de
datos
 Es mejor abortar una transacción que todavía debe hacer muchos cambios en la
base de datos.
Se trata de abortar las transacciones que supongan el mínimo coste.
Es necesario evitar la inanición.
 Timeouts

Una transacción que solicita un bloqueo sólo esperará durante un período de

tiempo predefinido por el sistema.
El inconveniente es que en un sistema sobrecargado el número de
transacciones que superan la temporización aumentará y las transacciones
que precisan un tiempo largo serán penalizadas.
Desventajas del Bloqueo
El mantenimiento del bloqueo representa una sobrecarga que no esta presente
en los sistema que no soportan acceso concurrente a los datos compartidos.

El uso de bloqueo puede producir un bloqueo indefinido.

Para impedir abortos en cascada, los bloqueo no pueden ser liberados hasta el
final de la transacción.

Kung y Robinson
 Control Optimista de la Concurrencia
Es un método de control de concurrencia que se aplica a sistemas
transaccionales, tales como sistemas de gestión de bases de datos
relacionales y memoria transaccional de software. Antes de hacer el commit,
cada transacción verifica que ninguna otra transacción ha modificado los
datos que ha leído. Si la comprobación revela modificaciones en conflicto, la
transacción que iba a hacer commit hace un rollback y se puede reiniciar.
Kung
 Control Optimista de la Concurrencia
Estrategias alternativas de resolver conflictos transacciones:
Arder
Abortar la transacciones que esta validado.

Abortar todas las transacciones conflictivas activas y consumar las

transacciones que están validando.

Aplazar la validación hasta un instante posterior cuando hayan finalizado las

transacciones conflictivas.

Inanición: es un problema relacionado con los sistemas multitarea, donde a

un proceso o un hilo de ejecución se le deniega siempre el acceso a un
recurso compartido. Sin este recurso, la tarea a ejecutar no puede ser nunca
finalizada.
Las apariciones de la inanición son probablemente rara, pero un servidor que
utiliza control de concurrencia optimista deben asegurar que un cliente no
sufre un aborto constantemente de una transacción.
 Ordenación por Marcas de Tiempos
En los esquemas de control de concurrencia basados en ordenación por
marcas de tiempos, cada operación es abortada inmediatamente y puede ser
reiniciada por el cliente. A cada transacción se le asigna un valor de marca de
tiempo único cuando comienza. La regla de ordenación básica por marca de
tiempo esta basada en los conflictos de operación:
Reglas

Regla Tc(actua Ti
l) (inicial)
1 Tc no debe escribir un objeto que haya sido leído por cualquier Ti
Escritura Lectura donde Ti > Tc’ esto require Tc >= a la mayor marca de tiempo de
lectura del objeto.
2 Tc no debe ser escribir un objeto que haya sido escrito por cualquier
Escritura Escritura Ti donde Ti > Tc’ esto requiere q Tc > la marca de tiempo de escritura
del objeto consumado.
3 Tc no debe leer un objeto que haya sido escrito por cualquier Ti donde
Lectura Escritura Ti >Tc’ esto requiere que Tc > la marca de tiempo de escritura del
 Regla de Escritura por Ordenación de Marca de Tiempo

Si ((Tc lectura >= la máxima marca de tiempo de lectura en D ) &&

(Tc escritura > la marca de tiempo de escritura en la versión consumada
de D))
realizar la operación de escritura en la versión tentativa de D con
marca de tiempo Tc.
De otro modo Ti Tc
aborta la transacción Tc.
Leer(D) Leer(D)
Escribir(
D) Escribir(
D)

Tiemp
o
Regla de Escritura por Ordenación de Marca de Tiempo

T1 < T2 < T3 <T4

(a)T3 escritura (b)T3 escritura

Antes T2 Antes T2 T4

Después T2 T3 Despué T2 T3 T4
s
Tiemp Tiemp
o o
Si ((Tc lectura >= la máxima marca de tiempo de
lectura en D ) &&
(c)T3 escritura
(Tc escritura > la marca e tiempo de escritura en
la versión consumada de D))

Antes T4 La transacción aborta realizar la operación de escritura en la

versión tentativa de D con marca de tiempo Tc.

Después T4 De otro modo

aborta la transacción Tc.
Tiemp
o
 Regla de Lectura por Ordenación de Marca de Tiempo

Si (Tc lectura > la marca de tiempo de escritura en la versión consumada de D)

sea D seleccionada la versión de D con máxima marca de tiempo de escritura Tc
Si (se ha consumado D seleccionada )
Realiza la operación de lectura en versión D seleccionada

de otro modo
Espera hasta la consumación de transacción que hizo
la versión D seleccionada o aborte después de replicar la regla de lectura
De otro modo Ti Tc
aborta la transacción Tc. Leer(D)
Escribir(
D) Leer(D)
Escribir(
D)
Tiemp
 Regla de Lectura por Ordenación de Marca de Tiempo

(a) T3 lectura (b) T3 lectura

Si (Tc lectura > la marca de tiempo de

escritura en la versión consumada de D)
T2 Prosigue la lectura T2 T4 Prosigue la lectura
sea D seleccionada la versión de D con
máxima marca de tiempo de escritura Tc
Si (se ha consumado D ) seleccionada seleccionada
seleccionada
Tiemp Tiemp
Realiza la operación de lectura en o o
versión D seleccionada
de otro modo
Espera hasta la consumación de
transacción que hizo (c) T3 lectura (d) T3 lectura
la versión D seleccionada o aborte después
de replicar la regla de lectura
De otro modo T1 T2 Lectura en espera T4 Transacción abortada
aborta la transacción Tc.

seleccionada
Tiemp Tiemp
o o
T1 < T2 < T3 <T4
 Ejercicio
1 2 3 4
Ti Tc Ti Tc Ti Tc Ti Tc

Leer(A) Leer(A) Leer(A) Leer(A) Leer(A) Leer(A)

Escribir(A) Escribir(A) Escribir(A) Escribir(A)
Leer(B)
Escribir(B) Leer(A)
Escribir(A) Escribir(A) Escribir(A)
Leer(B) Leer(B) Leer(B)
Leer(A)
Escribir(B) Escribir(B) Escribir(B)
Escribir(A)
Leer(B) Leer(B) Leer(B)
Leer(B) Escribir(B) Escribir(B)
Escribir(B)
Escribir(B)