Transacciones

Sistemas Distribuidos
Transacciones y Control de
Concurrencia
Agenda
Introduccin
Modelo de Fallos para Transacciones
Transacciones
Propiedades
Primitivas
Historia de Vida
Control de Concurrencia
Problema de las Actualizaciones perdidas

Problema de las Recuperaciones inconsistentes
Equivalente Secuencial
Operaciones Conflictivas
Recuperacin de Transacciones Abortadas.
Transacciones Anidadas
Planificacin de Transacciones
Bloqueos
Control Optimista
Marcas de Tiempo
2
Introduccin
En esta exposicin, presentamos la aplicacin de las transacciones

y control de concurrencia a los objetos compartidos gestionados por
un servidor.
Una transaccin define una secuencia de operaciones que se

realiza por el servidor, garantizando que es atmica, ya sea en
presencia de mltiples usuarios e incluso en cadas del servidor.
Presentamos tambin las transacciones anidadas, las mismas que

son estructuradas a partir de otras transacciones, que se utilizan en
SDs porque permiten concurrencia adicional.
Adems, detallaremos los protocolos de control de concurrencia,

basado en bloqueos, control optimista y ordenacin por marca
de tiempo.
3
Introduccin
Usamos transacciones para asegurar que todos los objetos

gestionados por el servidor permanezca en estado consistente,
cuando dichos objetos son accedidos por mltiples usuarios y en
presencia de cadas del servidor.
Una transaccin viene especificada como un conjunto de

operaciones que se realizan como una unidad indivisible sobre los
objetos gestionados por el servidor.
Los objetos que pueden recobrarse despus de la cada del servidor

se llaman recuperables; para ello el servidor puede utilizar
memoria persistente (disco) donde guarde informacin suficiente
para recobrar el estado de los objetos en caso caiga el servidor.
Los servidores deben garantizar que se realiza completamente la

transaccin y que los resultados se almacena en una memoria
permanente. En el caso de una o ms cadas, sus efectos se
eliminan completamente.
4
Introduccin
Nos concentramos en las transacciones relacionadas con un nico

servidor.
Cada transaccin de un cliente se considera tambin indivisible, en

el sentido de que las operaciones de una transaccin no pueden
observar los efectos parciales de otras transacciones
Estudiamos las transacciones en el contexto de los fallos por cada

de los procesos y omisin en la comunicacin.
Para explicar nuestras consideraciones, utilizamos un ejemplo

bancario, como se ve en la Figura 1. Cada cuenta est
representado por un objeto remoto cuya interfaz Cuenta
proporciona las operaciones de hacer depsitos y hacer reintegros y
para consultar y actualizar el balance. Cada sucursal del banco est
representado por un objeto remoto cuya interfaz Sucursal
proporciona operaciones para crear una nueva cuenta, para buscar
una cuenta por nombre y para preguntar por el total de los fondos
de la sucursal.
5
Consideraciones del ejemplo

deposita(cantidad)
deposita cantidad en al cuenta
extrae(cantidad)
saca la cantidad de la cuenta
obtenBalance() -> cantidad
devuelve el balance de la cuenta
ponBalance(cantidad)
inicializa el balance de la cuenta con la cantida
Operaciones de la interfaz Sucursal

crea(nombre) -> cuenta
Crea un nueva cuenta con el nombre especificado
busca(nombre) -> cuenta
Devuelve una referencia a la cuenta con el nombre especificado
totalSucursal() -> cantidad

Devuelve el total de todos los balances de la sucursal
Figura 1. Operaciones de la Interfaz Cuenta y
Sucursal
Modelo de Fallos para Transacciones
Lampson (1981) propuso un modelo de fallos para transacciones

distribuidas que considera fallos en los discos, servidores y
comunicaciones:
1. Las escrituras sobre almacenamiento permanente pueden
fallar, o porque no se escribe nada o porque se escribe un valor
incorrecto. Por ejemplo escribir en el bloque incorrecto es un
desastre.
2. Los servidores pueden fallar ocasionalmente. Cuando un
servidor averiado se reemplaza por un nuevo proceso, su
memoria voltil se sita en un estado en el que no conoce
ningn valor de antes de la ruptura; luego lleva a cabo un
proceso
de
recuperacin
utilizando
informacin
del
almacenamiento persistente y la obtenida de otros procesos.
3. Puede existir retardo arbitrario antes que llegue un mensaje.
Tanto los mensajes falsificados y corruptos se consider
El almacenamiento estable proporciona una operacin write atmica, an en

presencia de ruptura de proceso, esto se consigue replicando cada bloque en
dos bloques de disco.
Transacciones
Los clientes requieren una secuencia de operaciones que sean

atmicas en el sentido de:
1. Estn libres de interferencia por las operaciones de otros
clientes.
2. Todas las operaciones deben ser completadas con xito, de lo
contrario no tendrn ningn efecto si el servidor falla.
Las transacciones provienen de los sistemas de gestin de base de

datos. Es este contexto, una transaccin es un programa que accede
a la base de datos.
Las transacciones fueron introducidas en los SDs en la forma de

servidores de archivos transaccionales con XDFS. Una transaccin
es la ejecucin de una secuencia de peticiones de operaciones sobre
archivos de los clientes.
Para el cliente, una transaccin es una secuencia de operaciones

que forma un nico paso, transformando los datos del servidor de un
estado consistente a otro.
8
Transacciones, ejemplo
La figura 2 muestra una serie de acciones relacionadas con las

cuentas A, B y C, para ello utilizamos variables a, b y c de tipo
Cuenta.
Transaccin T:
a.extrae(100);
b.deposita(100);
c.extrae(200);
b.deposita(200);
Figura 2. Transaccin Bancaria de un Cliente
Las transacciones pueden venir dadas como parte del middleware.

Por ejemplo, CORBA OTS (Object Transaction Service).
Transacciones
Las transacciones constan de dos aspectos de atomicidad:

1. Todo o Nada. Una transaccin o finaliza correctamente (y todos sus
efectos son registrados en los objetos) o (si falla o es abortada) no
tiene ningn efecto. Esto tiene dos aspectos en s mismo:
Atomicidad de Fallo: los efectos son atmicos an en caso de
ruptura del servidor.
Durabilidad: despus de finalizado una transaccin, todos sus
efectos son guardados en almacenamiento permanente.
2. Aislamiento. Cada transaccin debe ser realizada sin interferencia
de otras transacciones.
Todos los cambios debidos a las transacciones completadas deben

estar disponibles en el almacenamiento permanente, de forma que
cuando un servidor es reemplazado por un nuevo proceso se pueda
recuperar los objetos para reflejar el efecto todo o nada.
El fin de todo servidor que soporta transacciones es maximizar la
concurrencia.
10
Propiedades ACID
Harder y Reuter (1983) sugirieron el nemotcnico ACID (Atomicity,

Consistency, Isolation, Durability), para recordar las transacciones.
A: Atomicidad (atomicity) propiedad todoonada.

En la recuperacion de caidas:
El sistema es quin tiene la responsabilidad de decidir qu
hacer ante la recuperacin de una falla:
Terminar de ejecutar el resto de las acciones.
Deshacer las acciones que se haba realizado.
Para proveer la recuperacin se usan tcnicas de
almacenamiento permanente.
11
Propiedades ACID
C: Consistencia (consistency) una transaccin toma el

sistema
en un estado consistente y lo deja en un estado consistente.
I: Aislamiento
(Isolation):
implica
seriabilidad
de
las
transacciones. Se les permite a las transacciones ejecutarse
concurrentemente si se obtiene el mismo efecto de una
ejecucin secuencial (serialmente equivalentes).
D: Durabilidad (durability)
12
Primitivas sobre Transacciones
Cada transaccin es creada y gestionada por un administrador que

implementa la interfaz Coordinador:
abreTransaccin() -> trans;
Comienza una nueva transaccin y proporciona una TID trans.
Este identificador ser utilizado en el resto de las operaciones
de la transaccin
cierraTransaccin(trans) -> (consumado, abortado);

Finaliza una transaccin.
Consumado: la transaccin termina exitosamente y sus
efectos van a almacenamiento permanente.
Abortado: no se reflejan los cambios. Los abortos pueden ser
causados por la propia naturaleza de la transaccin-
por conflictos con otras transacciones o por fallas.

abortaTransaccin(trans);
Aborta la transaccin.
read y write: tpicamente una transaccin se compone d
e
una serie de lecturas y escrituras y algunos clculos.
Figura 3. Operaciones en la Interfaz Coordinador
13
Historias de Vida de Transacciones
Con xito
abreTransaccin
operacin
operacin
Una transaccin o tiene xito o se aborta: el cliente la aborta o la aborta el

servidor. La figura 4 muestra las tres historias de vida alternativas para una
transaccin.
Abortado por el cliente
Abortado por el servidor
abreTransaccin
operacin
operacin
abreTransaccin
operacin
operacin
El servidor aborta
la transaccin
operacin
operacin
cierraTransaccin
abortaTransaccin
ERROR en la
operacin
reportada al
cliente
Figura 4. Historias de vida de una Transaccin

14
Control de Concurrencia de Transacciones
En esta seccin presentamos dos problemas bien conocidos en el

contexto del ejemplo bancario:
1. El problema de las actualizaciones perdidas:

2. El problema de las recuperaciones inconsistentes:
Suponemos:
Que cada operacin deposita, extrae, obtenBalance y
ponBalance, estn sincronizadas, o sea, sus efectos en la
variable de instancia es atmica.
15

1. El problema de las actualizaciones perdidas:
Los balances iniciales de las cuentas bancarias A,B y C son S/ 100,

S/ 200 y S/ 300, respectivamente.La transaccin T transfiere cierta
cantidad desde A hacia B. La transaccin U transfiere otra cantidad
desde C a B. En ambos casos la cantidad a transferir se calcula
para incrementar el balance de B en 10%. Los efectos netos de la
transferencia debiera ser S/ 242 en B.
Consideremos que Ty U se ejecutan concurrentemente, vea Figura

5. Ambas transacciones obtienen balance de B como S/ 200 y
despus depositan S/ 20. El resultado es incorrecto, al incrementar
el balance de B en S/ 20 en lugar de S/42.
Este es un ejemplo del problema de las actualizaciones perdidas. La

actualizacin de U se pierde porque T escribe sin mirar.
16

TransaccinT :
TransaccinU:
balance = b.obtenBalance();
b.ponBalance(balance*1.1);
a.extrae(balance/10)
balance = b.obtenBalance();
b.ponBalance(balance*1.1);
c.extrae(balance/10)
balance = b.obtenBalance();200
balance = b.obtenBalance();200
b.ponBalance(balance*1.1); 220
b.ponBalance(balance*1.1); 220
80
280
Figura 5. El problema de las actualizaciones perdidas

17

2. El problema de las recuperaciones inconsistentes:
La Figura 6 muestra otro ejemplo relacionado con una cuenta

bancaria. La transaccin V transfiere una suma desde A hacia B, y
la transaccin W invoca el mtodo totalSucursal() para obtener la
suma de los balances de todas las cuentas del banco.
Los balances de las dos cuentas, son inicialmente S/ 200. El

resultado de totalSucursal es S/ 300, lo cual es incorrecto.
Este es un ejemplo de recuperaciones inconsistentes. La

recuperacin de W son inconsistentes porque V haba realizado
slo la parte de la extraccin de su transferencia mientras se
calculaba la suma.
18

TransactionV:
a.extrae(100)
b.deposita(100)
a.extrae(100);
TransactionW:
unaSucursal.totalSucursal()
100
total = a.obtenBalance()
100
total = total+b.obtenBalance() 300

total = total+c.obtenBalance()
b.deposita(100)
300
Figura 6. El problema de las recuperaciones inconsistentes

19
EQUIVALENCIA SECUENCIAL
Si se sabe que cada una de las distintas transacciones tiene el

efecto correcto cuando se realiza ella sola, podemos inferir que si
estas transacciones se realizan una cada vez, en el mismo orden, el
efecto combinado tambin es correcto.
Un solapamiento de las operaciones de las transacciones, en las

que el efecto combinado es el mismo si las transacciones se
hubieran realizado una cada vez, en el mismo orden, se denomina
solapamiento secuencialmente equivalente.
El uso de la equivalencia secuencial como criterio para la

ejecucin concurrente correcta previene la ocurrencia de las
actualizaciones perdidas y las recuperaciones inconsistentes.
20
El problema de las actualizaciones perdidas ocurre cuando dos transacciones
leen el valor antiguo de una variable y la utilizan para calcular el nuevo valor.
Esto no puede ocurrir si una transaccin se realiza antes que la otra, porque la
ltima transaccin leer el valor escrito por el anterior. Vase Figura 7.
.
Transaccin T:
balance = b.obtenBalance()
b.ponBalance(balance*1.1)
TransaccinU:
b.ponBalance(balance*1.1)
balance = b.obtenBalance() 200

b.ponBalance(balance*1.1) 220
balance = b.obtenBalance() 220
b.ponBalance(balance*1.1) 242
80
Figura 7. Un solapamiento de T y U
secuencialmente equivalentes
278
21
El problema de las recuperaciones inconsistentes ocurre cuando
una transaccin de recuperacin se realiza antes de una
transaccin de actualizacin. Vase Figura 8.
Transaction V:
a.extrae(100);
b.extrae(100)
Transaction W:
unaSucursal.totalSucursal()
a.extrae(100);
100
b.deposita(100)
300
total = a.obtenBalance()
100
total = total+b.obtenBalance()
400
total = total+c.obtenBalance()
...
Figura 8. Un solapamiento de V y W secuencialmente equivalentes
22
Operaciones Conflictivas
Cuando decimos que un par de operaciones tiene conflictos, queremos decir que su
efecto combinado depende del orden en el que se ejecutan. Consideremos un par de
operaciones read(lee) y write(escribe), se dan las siguientes reglas de conflicto:
Operaciones de diferentes Conflicto

transacciones
read
read
No
Causa
Porque el efecto de un par de operaciones de lectura no
depende del orden en el que son ejecutadas
read
write
Si
Porque el efecto de una operacin de lectura y una de

escritura dependen del orden de su operacin
write
write
Si
Porque el efeto de un par de operaciones de escritura

Depende del orden de su ejecucin
Figura 9. Reglas de conflicto en las operaciones lee y escribe

23
RECUPERABILIDAD DE TRANSACCIONES ABORTADAS
Los servidores deben registrar todos los efectos de todas las

transacciones finalizadas y ninguno de los efectos de las
transacciones abortadas, considerando inclusive el hecho de que
una transaccin puede ser abortada en previsin de que afecte a
otras transacciones concurrentes, si es el caso.
Problemas: lecturas sucias y escrituras prematuras aun en

presencia de ejecuciones secuencialmente equivalentes.
Lectura Sucia: interaccin entre una operacin de lectura en una
transaccin y una operacin temprana de escritura en otra
transaccin sobre el mismo objeto.
Escrituras Prematuras: est relacionada con las interacciones
entre operaciones de escritura en el mismo objeto que se realiza en
diferentes transacciones.
24
EJECUCIONES ESTRICTAS DE LAS TRANSACCIONES

Se requiere que las transacciones retrasen sus operaciones de
lectura y escritura lo suficiente como para impedir tanto las lecturas
sucias como las escrituras prematuras.
Las operaciones de lectura y escritura sobre un objeto se
retrasan hasta que todas las transacciones que previamente
escribieron el objeto han sido consumadas o abortadas.
VERSIONES PROVISIONALES
Todas las operaciones de actualizacin realizadas por una
transaccin se hacen sobre versiones provisionales de los
objetos.
Las versiones provisionales son transferidas a los objetos slo
cuando una transaccin se consuma, registrndose tambin en
memoria permanente.
Si una transaccin aborta, sus versiones provisionales se borran.
25
Las transacciones pueden estar compuestas de otras. Por tanto, una

transaccin puede contener subtransacciones.
Problema: Si una transaccin interna realiza commit
(consumar
transaccin) y una ms externa abort (abortar), se pierden las

propiedades
de
atomicidad
y aislamiento por cumplir
con
la
durabilidad.
Generalmente la durabilidad slo se considera para la

transaccin ms externa.
En algunos sistemas, la transaccin superior puede decidir hacer

commit (consumar) an cuando alguna subtransaccin aborta.
El Servicio de Transacciones de Objetos OTS CORBA permite

transacciones planas y anidadas.
Ejemplo, vase Figura 10.

26
T : transaccin de nivel superior

T1 = abreSubTransaccion
T2 = abreSubTransaccion
T1 :
consumado
T2 :
abreSubTransaccion
T11 :
T12 :
consum. provis
abreSubTransaccion
consum. provis
consum. provis
abreSubTransaccion
T21 :
aborta
openSubTransaction
T211 :
consum. provis
consum. provis
Figura 10. Transacciones anidadas

27
1. Bloqueo Locking
Las transacciones deben planificarse de tal forma que sus efectos

sobre datos compartidos sean equivalentes.
Una forma sencilla es el uso de bloqueos exclusivos.
La Figura 11 ilustra el uso de bloqueos exclusivos. Muestra las

mismas transacciones de la Figura 7, pero con una columna extra
para cada transaccin que representa el bloqueo, la espera y el
desbloqueo.
En este ejemplo, suponemos que cuando inician las transacciones T y

U, las cuentas A, B y C no estn todava bloqueados.
Cuando la transaccin T va utilizar B, B se bloquea para T, y la
transaccin U espera. Cuando se consuma la transaccin T, B es
desbloqueado, despus del cual se reanuda la transaccin U.
El bloqueo de B serializa el acceso a B.
No est permitido a una transaccin ningn nuevo bloqueo despus
que ha liberado uno.
28
1. Bloqueo Locking
Transaction T:
b.ponBalance(bal*1.1)
a.extrae(bal/10)
Transaction U:
Operaciones
Operaciones
Bloqueos
c.extrae(bal/10)
Bloqueos
abreTransaccion
bal = b.obtenBalance() bloquea B
abreTransaccion
a.extrae(bal/10)
bloquea A
cierraTransaccion
desbloquea
AyB
bal = b.obtenBalance() espera por el

bloqueo de
de B por T
bloquea B
c.extrae(bal/10)
bloquea C
cierraTransaccion
desbloquea B y C
Figura 11. Transacciones T y U con bloqueos exclusivos
29
1. Bloqueo Locking
El nivel del 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 ser el grado

de paralelismo/concurrencia, pero mayor ser la complejidad
del
sistema.
El bloqueo puede ser a nivel de item, pgina, archivo, base

de datos (donde item representa el grano ms fino y base de
datos corresponde al grano ms grueso)
Nivel de granularidad del bloqueo: tiene que ver con el

tamao del objeto o dato que se est bloqueando
A mayor granularidad (mayor fineza del grano), ms pequeo es el

tamao del objeto.
30
1. Bloqueo Locking
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 hasta que l
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
para
cada mquina.
31
1. Bloqueo Locking
Para un objeto
Lock requested
Bloqueo ya activado
read
write
Ninguno
OK
OK
Lectura
OK
Espera
Escritura
Espera
Espera
Figura 12. Compatibilidad de Bloqueos
Una mejora: utilizar locks de escritura para ofrecer un mejor paralelismo al

permitir que se realicen concurrentemente transacciones que hagan operaciones
no conflictivas.
Otra mejora: promocin 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 otorgar el lock de escritura despus
de que todas las dems 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.
Esquema muchos lectores/ un escritor
32
1. Bloqueo Locking
Resuelve recuperaciones inconsistentes

No hay posibilidad de que dos operaciones conflictivas
se ejecuten concurrentemente
Resuelve prdida de actualizaciones

Si dos transacciones leen el mismo dato y luego lo
modifican,
la 2da. espera (ya sea por promocin o por no
otorgamiento)
El problema del algoritmo de locking es que puede

ocasionar deadlocks
(bloqueo
indefinido)
abortos
en
cascada, por lo que se han propuesto algunas variaciones

para evitar tales problema.
33
1. Bloqueo Locking
Two Phase Locking: obtencin y liberacin

Durante la fase de obtencin, la transaccin trata de
obtener
todos los locks que necesite. Si no es posible
obtener alguno, entonces espera.

La segunda fase comienza cuando la transaccin libera
alguno de los locks, a partir de ese momento no podr
solicitar ningn otro lock (si lo hace, ser abortada).
Desventaja: si una transaccin en la fase de liberacin
haba desbloqueado algunos objetos y los mismos
haban
sido accedidos por otras transacciones antes de que la

primera hiciera commit, entonces las dems transacciones
deberan abortar (esto es abortos en cascada).
34
1. Bloqueo Locking
Strict Two Phase Locking:

La fase de liberacin se realiza slo cuando la
transaccin hace commit (consumado).
La mejora: evita los abortos en cascada
Desventajas:
El nivel de paralelismo se degrada
Permanece la posibilidad de deadlock (bloqueo
indefinido).
An representa un alto costo de mantenimiento.
35
1. Bloqueo Locking
36
1. Bloqueo Locking
Desventajas:
El mantenimiento del bloqueo representa una sobrecarga que no

est presente en los sistemas que no soportan acceso concurrente
a los datos compartidos. Inclusive transacciones de slo lectura,
deben utilizar bloqueos para garantizar que los datos que leen no
sean modificados.
El uso de bloqueos puede producir bloqueos indefinidos (deadlock interbloqueos). La prevencin de interbloqueos indefinidos reduce
la concurrencia en forma severa; por tanto, un interbloqueo debe
ser resuelto mediante el uso de timeouts o mediante algoritmos de
deteccin de interbloqueos. Ninguno de ellos es satisfactorio en
aplicaciones interactivas.
Para impedir abortos en cascada, los bloqueos no pueden liberarse

hasta el final de la transaccin. Esto reduce el potencial de
concurrencia.
37
2. Control Optimista
Kung y Robinson (1981) proponen una ejecucin optimista.

Se basa en las siguientes premisas:
Los conflictos suceden poco
Como vaya viniendo vamos viendo
Adelante!, haz lo que quieras sin atender lo que los otros
hacen, no te preocupes por los problemas ahora,
preocpate ms tarde
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.
38
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 losdatos).
No hay posibilidad de lecturas sucias.
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 cambio
hechos sobre los espacios privados son actualizados en
las versiones originales.
39
Fase de Validacin:
Ante el close_transaction,
a cada transaccin se le asigna un
nmero (secuencial ascendente, i) que define su posicin en el
tiempo.
La validacin se basa en las siguientes reglas (i < j):
Ti
Tj
Regla
write
read
1.
Ti no debe leer datos escritos por
Tj
read
write
2.
Tj
no debe leer datos escritos por
Ti
write
write
3.
Ti
no debe escribir datos escritos por

Tj
no debe escribir datos escritos por
Tj and
Ti
Simplificacin: fases de validacin y escritura son secciones

crticas, entonces se satisface la regla 3. Slo hay que validar las
reglas 1 y 2.
40
Validacin hacia atrs:

Los reads de las Tj se realizaron antes que la validacin de Ti,
entonces se cumple la regla 1.
Slo se valida la regla 2 para cada Tj:
valid= true;
for (Tj=startTn+1;Tj<=finishTn,Tj++) {
if (read_set of Ti intersects write_set Tj)
valid=false;
}
startTn: Tj ms grande asignado a una transaccin committed
al momento que Ti entra a su fase de trabajo
finishTn: Tj ms grande asignado al momento que Ti entra a su
fase de validacin.
41
Validacin hacia atrs:

Slo es necesario validar los conjuntos de lectura. Las
transacciones que slo hacen escritura no se validan.
Si Ti no es vlida, se aborta
Trabajo
Validacin
Escritura
T1
Transacciones
anteriores commiteed
T2
T3
Transaccin
en validacin
recientes
transacciones
activas
Ti
activa
activa
42
Slo se validan T2 y T3. T1 termin antes que Ti comenzara.
Validacin hacia delante:

Se satisface la regla 2 porque las transacciones
escriben mientras que Ti no se ha completado.
Slo se valida la regla 1 para cada Tid:
valid= true;
for (Tid=activa1;Tid<=activaN,Tid++) {
if (write_set of Ti intersects read_set Tid)
valid=false;
}
activas
no
activaX: Representan transacciones que an no han entrado a

la fase de validacin
Las
transacciones que slo hacen lecturas no requieren ser
validadas.
43
Validacin hacia adelante:
Si Ti no es vlida:
Aplazar la validacin (le ir mejor en el futuro?)
Abortar las activas y consumar Ti
Abortar Ti (qu pasa si alguna de las futuras Tj es abortada?
Trabajo
Validacin
Escritura
T1
Transacciones
anteriores commiteed
T2
T3
Transaccin
en validacin
recientes
transacciones
activas
Ti
activa
activa
44
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.
este algoritmo produce mucha sobrecarga porque hay que
mantener los conjuntos de escritura de transacciones que
ya terminaron (hacia atrs).
45
3.
Ordenacin por Marcas de Tiempo (timestamp)

Las operaciones se validan al momento de ser ejecutadas
cuando una transaccin comienza, se le asigna un timestamp
(marca de tiempo).
Se trabaja con versiones tentativas.
Cada item de dato tiene asociado:
Un timestamp de escritura (Twrite_commit), un timestamp d
e lectura (Tread) y un conjunto de versiones tentativas con
su propio timestamp.
Un write aceptado genera una versin tentativa
Un read se dirige a la versin con el mximo timestamp menor

que el timestamp de la transaccin
46
3.

La validacin se basa en las siguientes reglas:
Regla Tj
Ti
1
write read
Condicin
Tj no debe escribir un dato ledo por Ti>Tj
(requiere que Tj >= max(Tread) del dato)
2
write
write Tj no debe escribir un dato escrito por
Ti>Tj (requiere que Tj > max
(Twrite_commit) del dato)
3
read
write
Tj no debe leer un dato escrito por Ti>Tj
(requiere que Tj > Twrite_commit
47
3.

Para saber cuando un write es vlido, se aplica el
siguiente
algoritmo (validacin de las reglas 1 y 2 regla de escritura):
Sea Tj una transaccin que desea hacer un write sobre el
objeto D.
If ((Tj >= Max (Tread en D)) &&
(Tj > write_commit en D))
Proceder con el write sobre una versin
tentativa nueva;
else // write is too late
Abortar Tj;
48
3.

Regla de escritura:
(b) T3 write
(a) T3 write
Before
T2
After
T2
T3
Before T1
T2
After
T2
T1
Clave:
Version Committed
T3
Time
Time
(c)
T3 write
Before
T1
Before
T4
Ti
Version Tentative
object produced
by transaction Ti
(with write timestamp Ti)
(d) T3 write
T4
Ti
Transaction
T1<T2<T3<T4
aborts
After
T1
T3
After
T4
Time
T4
Time
49
3.

Validacin de la regla 3 (regla de lectura): Tj hace read(D)
if (Tj > Twrite_commit en D) {
Dselected with Max (Twrite <=Tj en D);
if(esCommit (Dselected)) {
Procede el read sobre Dselected;
} else {
Esperar hasta que la Ti que hizo la versin
tentativa de Dselected haga commit o abort;
volver a comenzar;
} else {
Abortar Tj;
}
50
3.

Regla de lectura:
(a) T3 read
Key:
read
proceeds
T2
Seleccionado
T2
Time
T2
Seleccionado
Ti
Time
Version Committed
Ti
(d) T3 read
(c) T3 read
T1
read
proceeds
T4
Version Tentative
read waits
Seleccionado
T4
Time
Transaction
aborts
object produced
by transaction Ti
(with write timestamp Ti)
T1 < T2 < T3 < T4
Time
51
Bibliografa
Coulouris, George; Dollimore, Jean; Kindberg, Tim. Distributed

Systems: concepts and design. Forth Edition. Addison-Wesley
2007.
Harder, T. y Reuter. A. Principles of transactions-oriented

Database recovery. Computing survey. Vol. 5, N 4. 1983.
Kung, H. T. y Robinson, J. T. Optimistic methods for

concurrency control. ACM Transactions on Database System.
Vol. 6 N 22. 1981.
Lampson, B. W. Atomic transactions. En Distributed System:

Architecture and Implementation. Lecture Notes in Computer
Science 105. 1985.
52

Transacciones

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Transacciones

Cargado por

Copyright:

Formatos disponibles

Sistemas Distribuidos

Problema de las Actualizaciones perdidas

En esta exposicin, presentamos la aplicacin de las transacciones

Una transaccin define una secuencia de operaciones que se

Presentamos tambin las transacciones anidadas, las mismas que

Adems, detallaremos los protocolos de control de concurrencia,

Usamos transacciones para asegurar que todos los objetos

Una transaccin viene especificada como un conjunto de

Los objetos que pueden recobrarse despus de la cada del servidor

Los servidores deben garantizar que se realiza completamente la

Nos concentramos en las transacciones relacionadas con un nico

Cada transaccin de un cliente se considera tambin indivisible, en

Estudiamos las transacciones en el contexto de los fallos por cada

Para explicar nuestras consideraciones, utilizamos un ejemplo

Consideraciones del ejemplo

Operaciones de la interfaz Sucursal

totalSucursal() -> cantidad

Modelo de Fallos para Transacciones

Lampson (1981) propuso un modelo de fallos para transacciones

El almacenamiento estable proporciona una operacin write atmica, an en

Los clientes requieren una secuencia de operaciones que sean

Las transacciones provienen de los sistemas de gestin de base de

Las transacciones fueron introducidas en los SDs en la forma de

Para el cliente, una transaccin es una secuencia de operaciones

La figura 2 muestra una serie de acciones relacionadas con las

Las transacciones pueden venir dadas como parte del middleware.

Las transacciones constan de dos aspectos de atomicidad:

Todos los cambios debidos a las transacciones completadas deben

Harder y Reuter (1983) sugirieron el nemotcnico ACID (Atomicity,

A: Atomicidad (atomicity) propiedad todoonada.

C: Consistencia (consistency) una transaccin toma el

Primitivas sobre Transacciones

Cada transaccin es creada y gestionada por un administrador que

cierraTransaccin(trans) -> (consumado, abortado);

por conflictos con otras transacciones o por fallas.

Historias de Vida de Transacciones

Una transaccin o tiene xito o se aborta: el cliente la aborta o la aborta el

Abortado por el cliente

Abortado por el servidor

Figura 4. Historias de vida de una Transaccin

Control de Concurrencia de Transacciones

En esta seccin presentamos dos problemas bien conocidos en el

1. El problema de las actualizaciones perdidas:

Control de Concurrencia de Transacciones

Los balances iniciales de las cuentas bancarias A,B y C son S/ 100,

Consideremos que Ty U se ejecutan concurrentemente, vea Figura

Este es un ejemplo del problema de las actualizaciones perdidas. La

Control de Concurrencia de Transacciones

Figura 5. El problema de las actualizaciones perdidas

Control de Concurrencia de Transacciones

La Figura 6 muestra otro ejemplo relacionado con una cuenta

Los balances de las dos cuentas, son inicialmente S/ 200. El

Este es un ejemplo de recuperaciones inconsistentes. La

Control de Concurrencia de Transacciones

total = total+b.obtenBalance() 300

Figura 6. El problema de las recuperaciones inconsistentes

Control de Concurrencia de Transacciones

Si se sabe que cada una de las distintas transacciones tiene el

Un solapamiento de las operaciones de las transacciones, en las

El uso de la equivalencia secuencial como criterio para la

Control de Concurrencia de Transacciones

balance = b.obtenBalance() 200

Control de Concurrencia de Transacciones

Control de Concurrencia de Transacciones