iv control de transacciones
TRANSCRIPT
-
8/7/2019 IV Control De Transacciones
1/45
UNIDAD IV
CONTROL DE TRANSACCIONES
INTRODUCCIN.
Esta unidad trata de las transacciones, con las cuales se representa
una unidad lgica de procesamiento de b.d., adems se analizarn la
problemtica de los controles de concurrencia, y qu ocurre cuando
mltiples transacciones introducidas por varios usuarios seinterfieren d modo que los resultados obtenidos sean incorrectos.
IV. 1 SISTEMAS DE UNO Y DE VARIOS USUARIOS.
Un criterio para clasificar los sistemas de b.d. es por el nmero
de usuarios que pueden utilizarlos de manera concurrente, es decir, al
mismo tiempo.
Un SGBD es monousuario si un solo usuario a la vez puede
utilizarlo, y multiusuario si muchos usuarios pueden utilizarlo al mismo
tiempo.
El que muchos usuarios puedan utilizar los sistemas decomputadora al mismo tiempo se debe al concepto de
multiprogramacin, que permite a la computadora procesar
simultneamente varios programas o transacciones.
-
8/7/2019 IV Control De Transacciones
2/45
Si slo hay una unidad central de procesamiento (CPU), en
realidad slo se puede procesar un programa a la vez. Sin embargo,
los sistemas operativos de multiprogramacin ejecutan algunas
rdenes de un programa, luego suspenden ese programa y ejecutan
algunas rdenes del siguiente programa, y as sucesivamente.
Cuando a un programa le llega el turno de usar la CPU otra vez, se
reanuda su ejecucin en el punto en el que se suspendi.
As pues, la ejecucin concurrente de los programas es en
realidad intercalada, ver la siguiente figura.
A A
B B C CPU 1
D
CPU 2
T1 T2 T3 T4 tiempo
Figura 3.1 Concurrencia intercalada vs concurrencia
simultnea
En la primera parte de la figura se muestra la ejecucin
concurrente de dos programas A y B de manera intercalada. La
intercalacin mantiene ocupada a la CPU cuando un programa en
ejecucin requiere una operacin de entrada o de salida (E/S), como
leer un bloque de un disco.
Si la computadora cuenta con mltiples procesadores (CPU) en
hw, es posible el procesamiento simultneo de varios programas,
-
8/7/2019 IV Control De Transacciones
3/45
dando lugar a una concurrencia simultnea, no intercalada, como lo
ilustra la segunda parte de la grafica, con los programas C y D.
En un SGBD multiusuario, los elementos de informacin
almacenados son los recursos primarios a los que pueden tener acceso
concurrente los programas de usuarios, que constantemente obtienen
informacin de la b.d. y la modifican. A la ejecucin de un programa
que lee o modifica el contenido de la b.d. es a lo que llamamos una
transaccin.
IV. 2 OPERACIONES DE LECTURA Y ESCRITURA EN UNATRANSACCIN
Las operaciones de acceso a la b.d. que una transaccin puede
incluir son:
+ leer _ elemento(X): lee un elemento de la b.d. llamado X y
lo coloca en una variable de programa.
+ escribir _ elemento(X): escribe el valor de la variable de
programa X en el elemento de la b.d. llamado X.
Un bloque es la unidad bsica de transferencia de datos del
disco a la memoria principal de la computadora.
Un elemento de informacin ser un campo de algn registro
de la b.d., aunque puede ser una unidad mayor, como un registro o
incluso un bloque completo.
-
8/7/2019 IV Control De Transacciones
4/45
La ejecucin de una orden leer _ elemento( X) incluye los
siguientes pasos:
1. Encontrar la direccin del bloque de disco que contiene el
elemento X.
2. Copiar ese bloque de disco en un almacenamiento intermedio
(buffer) dentro de la memoria principal (si ese bloque no est ya
en almacenamiento intermedio).
3. Copiar el elemento X del almacenamiento intermedio a la
variable de programa llamada X.
La ejecucin de una orden escribir _ elemento(X) incluye
los siguientes pasos:
1. Encontrar la direccin del bloque de disco que contiene el
elemento X.
2. Copiar ese bloque de disco en un almacenamiento intermedio
dentro de la memoria principal (si ese bloque no est ya en
almacenamiento intermedio).
3. Copiar el elemento X desde la variable de programa llamada X al
lugar correcto dentro del almacenamiento intermedio.
4. Transferir el bloque actualizado desde el almacenamiento
intermedio al disco (ya sea de inmediato o en algn momento
posterior).
Este ltimo paso (4), es el que de hecho actualiza la b.d. en
disco. En algunos casos el almacenamiento intermedio no se transfiere
de inmediato al disco, por si fuera necesario hacer cambios en el buffer.
Por lo regular, la decisin sobre cundo almacenar en disco un bloque
-
8/7/2019 IV Control De Transacciones
5/45
modificado que est en un almacenamiento intermedio corresponde al
gestor de recuperacin o el sistema operativo.
Para tener acceso a la b.d., una transaccin deber incluir
operaciones leer _ elemento y escribir _ elemento; en la siguiente figura
se muestran ejemplos de dos transacciones simples, (a) transaccin T1
y (b) transaccin T2:
(a) leer _ elemento(X); (b) leer _ elemento(X);X:=X-N; X:=X+M;escribir _ elemento(X); escribir _ elemento(X);leer _ elemento(Y);Y:=Y+N;escribir _ elemento(Y);
Los mecanismos de control de concurrencia y de recuperacin
se ocupan principalmente de las rdenes de acceso a la b.d. incluidas en
una transaccin.
Las transacciones introducidas por los diversos usuarios se
podran ejecutar de manera concurrente y podran leer y actualizar los
mismos elementos de la b.d. Si esta ejecucin concurrente no se
controla, puede provocar que la b.d. no sea consistente.
-
8/7/2019 IV Control De Transacciones
6/45
IV.3 POR QU ES NECESARIO EL CONTROL DE CONCURRENCIA.
Pueden surgir varios problemas cuando las transacciones
concurrentes se ejecutan de manera no controlada.
El siguiente ejemplo que se emplea, trata sobre una b.d. simple
para hacer reservas en una lnea area, en la que se almacena un
registro por cada vuelo; cada registro incluye el nmero de asientos
reservados en ese vuelo, como elemento de informacin con nombre,
entre otra informacin.
La figura (a) muestra una transaccin T1 que cancela N
reservas de un vuelo, cuyo nmero de asientos reservados est
almacenado en el elemento de la b.d. llamado X, y reserva el mismo
nmero de asientos (N) en otro vuelo cuyo nmero de asientos
reservados est almacenado en el elemento de la b.d. llamado Y:
(a) leer _ elemento(X);X:=X-N;escribir _ elemento(X);leer _ elemento(Y);Y:=Y+N;escribir _ elemento(Y);
La figura (b) muestra una transaccin ms simple, T2, que se
limita a reservar M asientos en el primer vuelo al que hace referencia la
transaccin T1:
(b) leer _ elemento(X);X:=X+M;escribir _ elemento(X);
-
8/7/2019 IV Control De Transacciones
7/45
Cabe aclarar que para este ejemplo, cuando se escribe un
programa para la b.d., tiene como parmetros los nmeros de vuelos,
sus fechas y el nmero de asientos que se reservarn; por tanto, se
puede usar el mismo programa para ejecutar muchas transacciones,
cada uno con diferentes vuelos y nmeros de asientos por reservar.
En lo que al control de concurrencia concierne, una transaccin
es una ejecucin especfica de un programa sobre una fecha, un vuelo y
un nmero de asientos especficos.
En los ejemplos anteriores (a) y (b), las transacciones T1 y T2
son ejecuciones especficas de los programas que hacen referencia a los
vuelos especficos cuyos nmeros de asientos estn almacenados en los
elementos de informacin X y Y de la b.d.
Los tipos de problemas a los que podemos enfrentarnos con
este tipo de transacciones:
* Actualizacin Perdida:
Esto ocurre cuando dos transacciones que tienen acceso a los
mismos elementos de la b.d. tienen sus operaciones intercaladas de
modo que hacen incorrecto el valor de algn elemento.
Por ejemplo, supongamos que las transacciones T1 y T2 se
introducen aproximadamente al mismo tiempo, y que el sistema
operativo intercala sus operaciones, en tal caso, el valor final del
elemento X es incorrecto, porque T2 lee el valor de X antes de que T1 lo
modifique en la b.d., con lo que se pierde el valor actualizadoque
resulta de T1:
-
8/7/2019 IV Control De Transacciones
8/45
T1 T2
leer _ elemento(X);X:= X-N;
t leer _ elemento(X);i X:= X+M;e escribir _ elemento(X); el elemento X tiene un
m leer _ elemento(Y); valor incorrecto,porquep escribir _ elemento(X); su actualizacin por
T1o Y:= Y+N; se perdi
escribir _ elemento(Y);
(aplicar al ejemplo los siguientes valores: X=80 (originalmente haba 80
reservas en el vuelo), N=5 (T1 cancela cinco asientos en el vuelo que
corresponde a X y los reserva en el vuelo que corresponde a Y) y M=4
(T2 reserva cuatro asientos en X); el resultado final deber ser X=79;
sin embargo, con la problemtica X=84, porque la actualizacin que
cancel cinco asientos se ha perdido.)
* Actualizacin Temporal:
La actualizacin temporal en algunas ocasiones llamada lectura
sucia, ocurre cuando una transaccin actualiza un elemento de la b.d. y
luego la transaccin falla por alguna razn:
T1 T2
leer _ elemento(X);X:= X-N;
t escribir _ elemento(X);i leer _ elemento(X);e X:= X+M;m escribir _ elemento(X);po leer _ elemento(Y);
Otra transaccin tiene acceso al elemento actualizado antes de
que se restaure a su valor original. Este ejemplo muestra que T1
-
8/7/2019 IV Control De Transacciones
9/45
actualiza el elemento X y despus falla antes de completarse, as que el
sistema debe cambiar X otra vez a su estado o valor original. Antes de
que pueda hacerlo, la transaccin T2 lee el valor temporal de X, que
no se grabar permanentemente en la b.d. debido al fallo de T1. El
valor del elemento X que T2 lee se denomina dato sucio, porque fue
creado por una transaccin que no se complet ni se ha confirmado; por
ello, este problema se conoce tambin como problema de lectura
sucia.
* Resumen Incorrecto:
Si una transaccin est calculando una funcin agregada de
resumen sobre varios registros mientras otras transacciones estn
actualizando alguno de ellos, puede ser que la funcin agregada calcule
algunos valores antes de que se actualicen y otros despus de
actualizarse:
T1 T3
Suma:=0;
leer _ elemento(A);suma:=suma+A;leer _ elemento(X);X:=X-N;escribir _ elemento(X);
leer _ elemento(X); T3 lee X despus derestarse
suma:=suma+X; N y lee Y antes desumarse N,
leer _ elemento(Y); as que el resultado es unsuma:=suma+Y; resumen incorrecto
leer _ elemento(Y);Y:=Y+N;
escribir _ elemento(Y);
Por ejemplo, supongamos que una transaccin T3 est
calculando el nmero total de reservas de todos los vuelos; mientras
tanto, se est ejecutando la transaccin T1. Si ocurre la intercalacin
-
8/7/2019 IV Control De Transacciones
10/45
de operaciones que se muestra en la figura anterior, el resultado de T3
ser errneo por una cantidad N porque T3 lee el valor de X despus de
que se le han restado N asientos, pero lee el valor de Y antes de que se
le sumen esos N asientos.
IV.4 POR QU ES NECESARIO LA RECUPERACIN.
Siempre que se introduce una transaccin aun SGBD para
ejecutarla, el sistema tiene que asegurarse de que (a) todas las
operaciones de la transaccin se completen con xito y su efecto quede
asentado permanentemente en la b.d., o que (b) la transaccin no
tenga efecto alguno sobre la b.d. ni sobre cualquier otra transaccin.
El SGBD no debe permitir que se apliquen a la b.d. algunas
operaciones de una transaccin T pero otras operaciones de T s. Esto
puede suceder s una transaccin falla despus de ejecutar algunas de
sus operaciones, pero antes de ejecutarlas todas.
Tipos de Fallos; hay varias razones por las que una transaccin puede
fallar mientras se est ejecutando:
1. Fallo del HW y/o SW (cada): un error de hw o sw ocurre en el
sistema de cmputo durante la ejecucin de una
transaccin. Si el equipo falla, es posible que se pierda el
contenido de la memoria interna del computador.
2. Error de la transaccin o del sistema: alguna operacin de una
transaccin puede hacer que sta falle, (desbordamiento de
enteros o divisin entre cero, valores errneos de los
parmetros o a un error lgico de programacin, puede
-
8/7/2019 IV Control De Transacciones
11/45
suceder que el usuario interrumpa a propsito la transaccin
durante su ejecucin).
3. Errores locales o condiciones de excepcin detectadas por la
transaccin: durante la ejecucin de transacciones pueden
presentarse ciertas condiciones que requieran la cancelacin
de la transaccin; por ejemplo, es posible que no se
encuentren los datos para la transaccin; una condicin,
como un saldo insuficiente en una cuenta de una b.d.
bancaria, puede hacer que se cancele una transaccin, como
un retiro de fondos de esa cuenta.
4. Imposicin del control de concurrencia: el mtodo de control
de concurrencia puede decidir que se aborte la transaccin,
para reiniciarla despus, porque viola la seriabilidad o
porque varias transacciones se encuentran en un estado de
bloqueo mortal.
5. Fallo del disco: algunos bloques de disco pueden perder sus
datos por un mal funcionamiento de lectura o de escritura o
por un aterrizaje de una cabeza de lectura/escritura.
6. Problemas y catstrofes fsicos: esto se refiere a una
interminable lista de problemas que incluyen interrupcin del
suministro de energa, fallo del acondicionamiento de aire,
incendio, robo, sabotaje, sobreescritura en discos o cintas
por error, y que le operador haya montado la cinta
equivocada.
En muchas tcnicas de control de concurrencia y de
recuperacin de fallos, el concepto de transaccin atmica es
fundamental.
-
8/7/2019 IV Control De Transacciones
12/45
IV.5 CONCEPTOS DE TRANSACCIONES Y SISTEMAS
La ejecucin de un programa que incluye operaciones de
acceso a la b.d. se denomina transaccin de b.d. o simplemente
transaccin.
Una transaccin es una unidad atmica de trabajo que se
realiza por completo o bien no se efecta en absoluto.
En la mayora de las aplicaciones de las b.d. los usuarios
transmiten su trabajo en forma de transacciones, que tambin se
conocen como Unidades Lgicas de Trabajo(LUWs, Logical Units of
Work).
Una transaccin es una serie de acciones que llevarn a cabo
en la b.d., de tal manera que todas se ejecuten con xito, o que ningunase realice por completo; en ese caso la b.d. permanecer sin cambios.
Algunas veces esta transaccin se llama atmica, puesto que se
ejecuta como una unidad.
Estados de las transacciones y operaciones adicionales.
Para fines de recuperacin, el sistema necesita mantenerse al
tanto de cunto la transaccin se inicia, termina y se confirma o aborta.
Por lo tanto, el gestor de recuperacin se mantiene al tanto de las
siguientes operaciones:
-
8/7/2019 IV Control De Transacciones
13/45
INICIO_DE_TRANSACCION: sta marca el principio de la
ejecucin de la transaccin.
LEER o ESCRIBIR: stas especifican operaciones de lectura o
escritura de elementos de la b.d. que se efectan como parte de
una transaccin.
FIN_DE_TRANSACCIN: sta especifica que las operaciones
de LEER y ESCRIBIR de la transaccin han terminado y marca ellmite de la ejecucin de la transaccin. Sin embargo, en este
punto puede ser necesario verificar si los cambios introducidos
por la transaccin se pueden aplicar permanentemente a la b.d.
(confirmar) o si la transaccin debe abortarse porque viola el
control de concurrencia o por alguna otra razn.
CONFIRMAR_TRANSACCIN: sta seala que la transaccin
termin con xito y que cualesquiera cambios (actualizaciones)
ejecutadas por ella se pueden confirmar sin peligro en la b.d. y
que no se cancelarn.
REVERTIR (o ABORTAR): sta indica que la transaccin
trmino sin xito y que cualesquiera cambios o efectos que
pueda haber aplicado a la b.d. se deben cancelar.
DESHACER: similar a revertir, pero se aplica a una sola
operacin y no a una transaccin completa.
-
8/7/2019 IV Control De Transacciones
14/45
REHACER: sta especifica que ciertas operaciones de
transaccin se deben repetir (rehacer) para asegurar que todas
las operaciones de una transaccin confirmada se hayan aplicado
con xito a ala b.d.
LEER,ESCRIBIR
INICIO_DE_ FIN_DE_ TRANSACCIN TRANSACCIN CONFIRMAR
ACTIVA PARCIALMENTE CONFIRMADACONFIRMADA
ABORTAR ABORTAR
FALLIDA
TERMINADA
La figura muestra un diagrama de transicin de estados
que describe el paso de una transaccin por sus estados de ejecucin:
1) Una transaccin entra en un estado activo inmediatamentedespus de que inicia su ejecucin, y ah puede emitir
operaciones LEER y ESCRIBIR.
2) Cuando la transaccin termina, pasa al estado parcialmente
confirmado; en este punto, algunas tcnicas de control de
concurrencia requieren que se efecten ciertas verificaciones
para garantizar que la transaccin no interfiere otrastransacciones en ejecucin. Algunos protocolos de
recuperacin deben asegurar que un fallo del sistema no
provocar una incapacidad para registrar permanentemente los
-
8/7/2019 IV Control De Transacciones
15/45
cambios hechos por la transaccin (usualmente asentando los
cambios en una bitcora del sistema).
3) Una vez realizadas con xito ambas verificaciones, se dice que la
transaccin ha llegado a su punto de confirmacin y pasa al
estado confirmado. Una vez que una transaccin est en el
estado confirmado, ha concluido con xito su ejecucin.
4) Sin embargo, una transaccin puede pasar al estado fallido si
una de las verificaciones falla o si la transaccin se aborta
mientras est en el estado activo. En tal caso, es posible que
la transaccin deba revertirse para anular los efectos de sus
operaciones ESCRIBIR sobre la b.d.
5) El estado terminado corresponde al abandono del sistema por
parte de la transaccin. Las transacciones fallidas o abortadas
pueden reiniciarse posteriormente, ya sea en forma automtica
o despus de reintroducirse como transacciones nuevas.
Bitcora del sistema.
Para poderse recuperar de los fallos de transacciones, el
sistema mantiene una bitcora (diario) que sigue la pista a todas las
operaciones de transacciones que afectan los valores de elementos de la
b.d.
La bitcora se mantiene en disco, de modo que no la afecta
ningn tipo de fallo, ms que los de disco o los catastrficos. Adems,
-
8/7/2019 IV Control De Transacciones
16/45
la bitcora se respalda peridicamente en cinta para protegerse contra
estos tipos de fallos.
A continuacin se mencionan los tipos de entradas que se
escriben en la bitcora y la accin que realiza cada una de ellas. En
estas entradas, T se refiere a un identificador de transaccin nico que
el sistema genera automticamente y que sirve para identificar cada
transaccin:
[inicio_de_transaccin, T]: asienta que se ha iniciado la
ejecucin de la transaccin T.
[escribir_elemento, T, X, valor_anterior, nuevo_valor]: asienta
e la transaccin T cambi el valor del elemento de
d. X de valor_anterior a nuevo_valor.
3. [leer_elemento, T, X]: asienta que la transaccin T ley el
lor del elemento de b.d. X.
4. [confirmar, T]: asienta que la transaccin T termin con xito
stablece que su efecto se puede confirmar (asentar
permanentemente) en al b.d.
5. [abortar, T]: asienta que se abort la transaccin T.
Si se supone que todos los cambios permanentes de la b.d.
ocurren dentro de las transacciones, entonces la nocin de recuperarse
de una transaccin equivale a deshacer o rehacer las operaciones
recuperables individualmente a partir de la bitcora.
Si el sistema se cae, podemos recuperar la b.d. a un estado
consistente examinando la bitcora y usando tcnicas de recuperacin.
-
8/7/2019 IV Control De Transacciones
17/45
Dado que la bitcora contiene un registro de cada operacin
ESCRIBIR que altera el valor de algn elemento de la b.d., es posible
deshacer (cancelar) el efecto de estas operaciones ESCRIBIR de una
transaccin T rastreando hacia atrs en la bitcora y restableciendo
todos los elementos alterados con una operacin ESCRIBIR de T a su
valor_anterior.
Tambin podemos rehacer el efecto de las operaciones
ESCRIBIR de una transaccin T rastreando hacia delante en la bitcora y
cambiando todos los elementos modificados por una operacin
ESCRIBIR de T a su nuevo_valor.
Punto de confirmacin de una transaccin.
Una transaccin T llega a su punto de confirmacin cuando
todas sus operaciones que tienen acceso a la b.d. se han ejecutado con
xito y el efecto de todas estas operaciones se ha asentado en la
bitcora, es decir, que la transaccin est confirmada, y se supone que
su efecto se asent permanentemente en la b.d. En ese momento la
transaccin escribe una entrada [confirmar, T] en la bitcora.
Si ocurre un fallo del sistema, buscamos en la bitcora todas las
transacciones T que han escrito una entrada [inicio_de_transaccin, T]
en la bitcora pero no han escrito todava su entrada [confirmar, T]; es
posible que durante el proceso de recuperacin estas transacciones
tengan que revertirse para cancelar su efecto sobre la b.d. Las
transacciones que ya escribieron su entrada de confirmacin en la
bitcora tambin debern haber asentado en ella todas sus operaciones
-
8/7/2019 IV Control De Transacciones
18/45
ESCRIBIR, pues de lo contrario no estaran confirmadas; su efecto sobre
la b.d. puede rehacerse a partir de las entradas de la bitcora.
El archivo de la bitcora debe mantenerse en disco; por lo que la
actualizacin de un archivo en disco implica copiar el bloque apropiado
del archivo del disco a un almacenamiento intermedio en la memoria
principal, actualizar este almacenamiento intermedio y copiarlo de la
memoria principal al disco.
Con frecuencia se mantiene un bloque del archivo de bitcora
en la memoria principal hasta que se llena de entradas y luego se
escribe una sola vez en el disco, en vez de escribirlo cada vez que se
aade una entrada; esto ahorra el gasto extra de escribir varias veces
en el disco el mismo bloque de archivo. Cuando se cae el sistema,
slo las entradas de bitcora que se han escrito en disco se considera
que estn en el proceso de recuperacin, porque pueden haberse
perdido el contenido de la memoria principal.
Por ello, antes de que una transaccin llegue a su punto de
confirmacin, cualquier porcin de la bitcora que no se haya escrito en
el disco todava se deber grabar. Este proceso se denomina forzar la
escritura del archivo de bitcora antes de confirmar una transaccin.
Puntos de control en la bitcora del sistema.
Otro tipo de entrada en la bitcora es el llamado punto de control.
Un registro [punto_de_control] se escribe en la bitcora peridicamente
cada vez que el sistema escribe en la b.d. en disco el efecto de todas las
operaciones ESCRIBIR de las transacciones confirmadas. As pues,
-
8/7/2019 IV Control De Transacciones
19/45
todas las transacciones que tengan sus entradas [confirmar,T] en la
bitcora antes de una entrada [punto_de_control] no necesitarn la
repeticin de sus operaciones ESCRIBIR en caso de una cada del
sistema.
El gestor de recuperacin de un SGBD debe decidir con qu
intervalos asentar un punto de control. El intervalo puede medirse en
el tiempo (cada m minutos) o por el nmero t de transacciones
confirmadas desde el ltimo punto de control, donde los valores de m o
de t son parmetros del sistema.
El asentamiento de un punto de control consiste en las siguientes
acciones:
1 Suspender temporalmente la ejecucin de las transacciones.
2 Forzar la escritura de todas las operaciones de actualizacin
pertenecientes a transacciones confirmadas del
almacenamiento intermedio al disco.
3 Escribir un registro [punto_de_control] en la bitcora y forzar
la escritura de la bitcora en el disco.
4 Reanudar la ejecucin de transacciones.
Un registro de punto de control en la bitcora tambin puede incluir
informacin adicional, como una lista de identificadores de las
transacciones activas o las ubicaciones (direcciones) del primer registro
y del ms reciente (ltimo) en la bitcora para cada transaccin activa.
Esto puede facilitar la anulacin de operaciones en caso de ser necesaria
la reversin de una transaccin.
-
8/7/2019 IV Control De Transacciones
20/45
IV.6 PROPIEDADES DESEABLES EN LAS TRANSACCIONES.
Las transacciones atmicas deben poseer varias propiedades.
stas se conocen como propiedades ACID (Atomic, Consistent,
Insolated y Durable), y deben ser impuestas por los mtodos de control
de concurrencia y de recuperacin del SGBD:
- Atomicidad : Una transaccin es una unidad de procesamiento;
o bien se realiza por completo o no se realiza en absoluto.
- Conservacin de la consistencia : Una ejecucin correcta de
la transaccin debe llevar a la b.d. de un estado consistente a
otro.
- Aislamiento : Unas transaccin no debe dejar que otras
transacciones puedan ver sus actualizaciones antes de que sea
confirmada; esta propiedad, cuando se hace cumplir
estrictamente, resuelve el problema de la actualizacin temporal
y hace innecesaria las reversiones en cascada de las
transacciones.
- Durabilidad o permanencia : Una vez que una transaccin
ha modificado la b.d. y las modificaciones se han confirmado,
stas nunca deben perderse por un fallo subsecuente.
Es obligacin del mtodo recuperacin garantizar la atomicidad.
Si por alguna razn una transaccin no puede completarse, como por
una cada del sistema ala mitad de su ejecucin, el mtodo de
-
8/7/2019 IV Control De Transacciones
21/45
recuperacin debe cancelar todos los efectos de la transaccin sobre la
b.d.
Se considera que la propiedad de conservacin de la
consistencia es responsabilidad de los programadores que escriben los
programas de b.d. o del mdulo de SGBD que impone las restricciones
de integridad. Recuerde que un estado de la b.d. es una coleccin de
todos los elementos de informacin (valores) almacenados en la b.d. en
un momento dado. Un estado consistente de la b.d. satisface las
restricciones especificadas en el esquema, adems de cualesquier otras
restricciones que deban cumplirse en la b.d. Los programas de b.d.
deben elaborarse a modo de garantizar que, si la b.d. est en un estado
consistente antes de ejecutar la transaccin, estar en un estado
consistente despus de la ejecucin completa de la transaccin,
suponiendo que no hay interferencias con otras transacciones.
IV.7 TRANSACCIONES CONSISTENTES.
Como se acaba de leer, una transaccin atmica es aquella en
la que todas las acciones de la b.d. pueden ocurrir, o tambin ninguna.
Una transaccin durable es aquella para la que todos los cambios
confirmados son permanentes. El SMBD no eliminar esos cambios,
incluso en el caso de fracasar. Si la transaccin es durable, el SMBD
proporcionar las facilidades para recuperar los cambios de todas las
acciones confirmadas cuando sea necesario.
-
8/7/2019 IV Control De Transacciones
22/45
Sin embargo, los trminos consistentes y aislados no son tan
definitivos como atmicos y durables. Considere la siguiente
instruccin de actualizacin de SQL:
UPDATE CLIENTE
SET Cdigoderea = 425
WHERE CdigoPostal = 98050
Suponga que hay 500,000 tuplas en la tabla CLIENTE y que
500 tienen CdigoPostal igual a 98050; le tomar algn tiempo al
SMBD encontrar las 500 tuplas, durante ese tiempo, Otras
transacciones permitirn actualizar los campos de Cdigoderea o
CdigoPostalde CLIENTE? Si la instruccin de SQL es consistente,
estas actualizaciones estarn prohibidas. La actualizacin se aplicar
para establecer que las tuplas como stas existen en el momento en que
el enunciado de SQL inici; esta consistencia se llama Consistencia
del Nivel de Instruccin.
Ahora considere una transaccin que contenga dos
instrucciones de actualizacin de SQL:
BEGIN TRANSACTION
UPDATE CLIENTE
SET Cdigorea = 425
WHERE CdigoPostal = 98050
(Otra transaccin en funcionamiento)
UPDATE CLIENTE
-
8/7/2019 IV Control De Transacciones
23/45
SET Descuento = 0.05
WHERE Cdigorea = 425
(Otra transaccin en funcionamiento)
COMMIT TRANSACTION
En este contexto, qu significa consistente? La
consistencia del nivel de instruccin que quiere decir que cada
instruccin procesa independientemente tuplas consistentes, pero que
los cambios de otros usuarios de estos renglones se pueden permitir
durante el intervalo entre las dos instrucciones SQL. El nivel de
consistencia de la transaccin significa que todos las tuplas impactadas
por cualquiera de las instrucciones SQL son protegidos de cambios
durante la transaccin completa. Observe, sin embargo, que para
algunas implementaciones de la consistencia del nivel de transaccin,
una transaccin no ver sus propios cambios. En este ejemplo, la
segunda instruccin SQL puede no ver los cambios en las tuplas
derivadas de la primera instruccin SQL.
As, que se debe tener cuidado o poner ms atencin para
determinar qu tipo de consistencia se refiere, as como, de no caer en
la trampa potencial de consistencia del nivel de transaccin. El
trmino aislada, se considera a continuacin.
IV.8 NIVEL DE AISLAMIENTO DE LA TRANSACCIN.
Los locks evitan que los procesos concurrentes ocasionen la
prdida de actualizaciones; pero hay otro tipo de problemas que no
evitan. Especficamente, ocurre una lectura sucia cuando una
-
8/7/2019 IV Control De Transacciones
24/45
transaccin lee un registro cambiado que no ha sido registrado en la
base de datos. Por ejemplo, esto puede ocurrir si una transaccin lee
un rengln cambiado por una segunda transaccin no confirmada, la
cual ms tarde aborta.
Las lecturas no repetibles ocurren cuando una transaccin relee
datos que fueron ledos con anterioridad y encuentra modificaciones o
eliminaciones ocasionadas por una transaccin confirmada. Por ltimo,
las lecturas fantasmas tienen lugar cuando una transaccin relee los
datos y encuentra que se insertaron nuevos renglones como resultado
de una transaccin confirmada en la lectura anterior.
El estndar ANSI SQL de 1992 define cuatro niveles de
aislamiento, que especifican cul de estos problemas se permite que
ocurra. El objetivo es que el programador de la aplicacin pueda
declarar el tipo de nivel de aislamiento que quiere y entonces tener la
administracin de los locks del SMBD, as como lograr ese nivel de
aislamiento.
Como se muestra en la figura, la lectura en un nivel de
aislamiento no confirmado permite que ocurran lecturas sucias, lecturas
no repetibles y lecturas fantasmas. Con aislamiento de lecturas
confirmadas, las lecturas sucias estn prohibidas. El nivel de
aislamiento de lecturas repetibles prohbe tanto las lecturas sucias como
las no repetibles. El nivel de aislamiento serializable no permitir que
ocurran ninguna de las tres.
Por lo general, el nivel ms restrictivo, de no menor
rendimiento efectivo, depende mucho de la carga de trabajo y de cmo
estn escritos los programas de aplicacin. Adems, no todos los
-
8/7/2019 IV Control De Transacciones
25/45
productos SMBD usan todos estos niveles. Los productos tambin
varan en la manera en la cual se manejan y en cuanto a la carga que
ponen en el programador de la aplicacin.
IV.9 PLANES Y RECUPERABILIDAD
Cuando varias transacciones se ejecutan de manera
concurrente e intercalada, el orden de ejecucin de sus operaciones
constituyen lo que se conoce como plan (o historia) de las
transacciones.
Planes (historias) de transacciones.
Un plan (o historia) P de n transacciones T1, T2,..,Tn en un
ordenamiento para las operaciones de las transacciones sujeto a la
restriccin de que, para cada transaccin T i que participe en P, las
operaciones de Ti en P deben aparecer en el mismo orden en que
ocurren en Ti.
NIVEL DE AISLAMIENTO
Lectura Lectura Lectura
No Confirmada Confirmada Repetible Serializable
Posible No Posible No Posible No Posible
Posible Posible No Posible No Posible
Posible Posible Posible No Posible
Lectura Sucia
Tipo
De Lec. No Repetible
ProblemaLectura Fantasma
-
8/7/2019 IV Control De Transacciones
26/45
Para fines de recuperacin y control de concurrencia, nos
interesan principalmente las operaciones leer _ elemento y escribir _
elemento de las transacciones, as como las operaciones de confirmar y
abortar.
Una notacin abreviada para escribir un plan emplea los
siguientes smbolos:
Leer _ elemento ( l ) Confirmar ( c )
Escribir _ elemento ( e ) Abortar ( a )
A esta notacin se le aade como subndice el identificador de
la transaccin (nmero de la transaccin) a cada operacin del Plan.
En esta notacin, el elemento de la b.d. que se lee o escribe, X, sigue a
las operaciones l y e entre parntesis.
Por ejemplo, el plan de las figuras (a) y (b), que llamaremos Pa,
se puede escribir como sigue despus de aadirle las operaciones de
confirmacin:
Pa: l1 (X); l2 (X); e1 (X); l1 (Y); e2 (X); c2; e1 (Y); c1;
(a)
T1 T2
leer _ elemento(X);X:= X-N;
t leer _ elemento(X);i X:= X+M;e escribir _ elemento(X); el elemento X tiene
unm leer _ elemento(Y); valor incorrecto,
porque
-
8/7/2019 IV Control De Transacciones
27/45
p escribir _ elemento(X); su actualizacinpor T1
o Y:= Y+N; se perdiescribir _ elemento(Y);
Pb: l1 (X); e1 (X); l2 (X); e2 (X); c2; l1 (Y); a1;
(b)
T1 T2
leer _ elemento(X);X:= X-N;
t escribir _ elemento(X);i leer _ elemento(X);e X:= X+M;m escribir _ elemento(X);po leer _ elemento(Y);
la transaccin T1 falla y debe volver el valor
de X a su antiguo valor; mientras tanto T2 ha
ledo el valor temporal incorrecto de X.
Se dice que dos operaciones de un plan estn en conflicto si
pertenecen a diferentes transacciones, si tienen acceso al mismo
elemento X y si una de las dos operaciones es escribir _ elemento(X).
En el plan Pa, las operaciones l1 (X) y e2 (X) estn en conflicto,
lo mismo que l2 (X) y e1 (X), y que e1 (X) y e2 (X). Sin embargo, las
operaciones l1 (X) y l2 (X) no estn en conflicto porque son operaciones
de lectura; y las operaciones e2 (X) y e1 (Y) tampoco estn en conflicto,
porque operan sobre diferentes elementos de informacin, X e Y.
-
8/7/2019 IV Control De Transacciones
28/45
Un plan P de n transacciones T1, T2,., Tn es un plan completo
si se cumplen las siguientes condiciones:
1. Las operaciones de p son exactamente las operaciones de T1, T2,
, Tn, incluidas una operacin de confirmar o de abortar como
ltima operacin de cada transaccin en el plan.
2. Para cualquier par de operaciones de la misma transaccin Ti, suorden de aparicin en P es el mismo que su orden de aparicin
en Ti.
3. Para cualesquier dos operaciones en conflicto, una de ellas debe
ocurrir antes que la otra en el plan.
Las condiciones anteriores permiten que dos operaciones que
no estn en conflicto ocurran en el plan sin definir cul lo haga primero,dando lugar a la definicin de un plan como un orden parcial de las
operaciones en las n transacciones. Sin embargo, se debe especificar
un orden total en el plan para cualquier par de operaciones en conflicto
(condicin 3) y para cualquier par de operaciones de la misma
transaccin (condicin 2); y la condicin 1 simplemente dice que todas
las operaciones en las transacciones deben aparecer en el plan
completo. Puesto que toda transaccin ha sido confirmada o abortada,
un plan completo nunca contendr transacciones activas.
-
8/7/2019 IV Control De Transacciones
29/45
IV.10 SERIABILIDAD DE LOS PLANES.
En el SGBD se introducen las transacciones T1 Y T2
aproximadamente al mismo tiempo:
(a) leer _ elemento (X); (b) leer _ elemento (X);
X:=X-N; X:=X+M;
escribir_elemento(X); escribir_elemento(X);
leer_elemento(Y);
Y:=Y+N;
Escribir_elemento(Y);
Si no se permite la intercalacin, slo hay dos formas posiblesde ordenar las operaciones de las dos transacciones para su ejecucin:
1. Ejecutar todas las operaciones de la transaccin T1 (en orden)
seguidas de todas las operaciones de la transaccin T2 (en
orden).
Plan a)
T1 T2
leer_elemento (X);X:=X-N;escribir_elemento(X);leer_elemento (Y);
-
8/7/2019 IV Control De Transacciones
30/45
Y:=Y+N;escribir_elemento (Y);
leer_elemento(X);X:=X+M;escribir_elemento(X);
2. Ejecutar todas las operaciones de la transaccin T2 (en orden)
seguidas de todas las operaciones de la transaccin T1 (en
orden).
Plan b)
T1 T2
leer_elemento(X);X:=X+M;escribir_elemento(X);
leer_elemento (X);X:=X-N;escribir_elemento(X);leer_elemento (Y);Y:=Y+N;escribir_elemento (Y);
Si se permite la intercalacin de operaciones, habr muchos
rdenes posibles en que el sistema podr ejecutar las operaciones
individuales de las transacciones. Dos posibles planes se ilustran a
continuacin:
Plan c)T1 T2
leer_elemento (X);X:=X-N;
leer_elemento(X);X:=X+M;
escribir_elemento(X);leer_elemento (Y);
escribir_elemento(X);
-
8/7/2019 IV Control De Transacciones
31/45
Y:=Y+N;escribir_elemento (Y);
Plan d)
T1 T2leer_elemento (X);X:=X-N;Escribir_elemento(X);
leer_elemento(X);
X:=X+M;escribir_elemento(X);
leer_elemento (Y);Y:=Y+N;escribir_elemento (Y);
Un aspecto importante del control de concurrencia es la
llamada teora de la seriabilidad, con la que se intenta determinarcules planes son correctos y cules no, e inventar tcnicas que slo
permitan planes correctos.
Planes en serie, no en serie y seriables por conflictos.
Un plan P es en serie si, por cada transaccin T que participa
en el plan, todas las operaciones de T se ejecutan consecutivamente en
el plan; de lo contrario, el plan no es en serie.
Una suposicin razonable que se puede hacer es que si
consideramos que las transacciones son independientes, es que todo
plan en serie se considera entonces correcto. La razn es que
-
8/7/2019 IV Control De Transacciones
32/45
suponemos que toda transaccin es correcta si se ejecuta por s sola, y
que las transacciones son independientes entre s; por ello, no importa
cul transaccin se ejecute primero. En tanto toda transaccin se
ejecute de principio a fin sin que la interfieran las operaciones de otras
transacciones, obtendremos un resultado final correcto en la b.d.
Pero esto genera un problema, limitan la concurrencia o la
intercalacin de las operaciones; es decir, si en un plan en serie, una
transaccin est esperando que se complete una operacin de E/S, no
podremos conmutar el procesador a otra transaccin, desperdicindose
as un tiempo valioso de procesamiento de la CPU y haciendo a los
planes en serie inaceptables en general.
Al aplicar los valores siguientes a los planes a y b, X = 90 y Y =
90, y que N = 3 y M = 2; el resultado arrojado de las transacciones T 1 y
T2 en la B.D. son de Y = 89 y Y = 93.
Pero al aplicar los mismos valores al plan c, da resultados
incorrectos por presentar el problema de la actualizacin perdida alobtener X = 92 y Y =93; esto es, la transaccin T2 lee el valor de X antes
de que la transaccin T1 lo modifique, as que slo el efecto de T2 sobre
X se refleja en la b.d., el efecto de T1 sobre X se pierde, pues T2 lo
sobrescribe, dando lugar al resultado incorrecto para el elemento X.
No obstante, algunos planes no en serie producen el resultado
correcto esperado, como sucede con el plan d.
Lo importante en esto es determinar cules de los planes no en
serie siempre dan un resultado correcto y cules pueden dar resultados
errneos; es decir, el concepto con el que se caracterizan los planes de
esta manera es el de la seriabilidad de un plan.
-
8/7/2019 IV Control De Transacciones
33/45
Un plan P de n transacciones es seriable si es equivalente a
algn plan en serie de la misma n transacciones. De igual manera,
decir que un plan no en serie P es seriable, equivale a decir que es
correcto, porque es equivalente a un plan en serie, que se considera
correcto.
Pero qu se debe de entender por equivalente?, la definicin
ms simple, pero no menos satisfactoria, implica comparar los efectos
de los planes sobre la b.d. Se dice que dos planes son equivalentes
por resultados si producen el mismo estado final en la b.d.
Sin embargo, dos planes distintos pueden producir el mismo
estado final por accidente; por ejemplo, en la siguiente figura, los planes
P1 y P2 producen el mismo estado final si se ejecutan en una b.d. en la
que el valor inicial de X es 100, pero para otros valores iniciales de X los
dos planes no son equivalentes por resultados; de igual manera, estos
dos planes ejecutan diferentes transacciones, por lo que en definitiva no
deben considerarse equivalentes.
P1 P2
leer _ elemento (X); leer _ elemento (X);
X:= x + 10; X:= x*1.1;
escribir _ elemento (X); escribir _ elemento (X);
El enfoque ms seguro y general para definir la equivalencia de
dos planes consiste en no hacer suposicin alguna sobre los tipos de
operaciones que intervienen en las transacciones. Para que dos planes
sean equivalentes, las operaciones que se aplican a cada uno de los
elementos de informacin afectados por los planes se deben aplicar a
ese elemento en el mismo orden en ambos planes. Por lo regular se
-
8/7/2019 IV Control De Transacciones
34/45
aceptan dos definiciones de equivalencia de planes: equivalencia por
conflictos y equivalencia de vistas.
IV.11 PROCESAMIENTO DE TRANSACCIONESCONCURRENTES.
Cuando se han procesado dos transacciones en una b.d. al
mismo tiempo, se les llama transacciones concurrentes. Aun cuando
al usuario le pueda parecer que las transacciones concurrentes se han
procesado en forma simultnea, esto no puede ser verdad, ya que el
CPU de la mquina que est procesando la b.d. slo puede ejecutar una
instruccin a la vez.
Por lo general las transacciones estn mezcladas, lo que
significa que el sistema operativo alterna los servicios del CPU entre las
tareas para que alguna parte de cada una de ellas se realice en un
intervalo determinado.
El siguiente ejemplo muestra dos transacciones concurrentes,
la del usuario A y las del usuario B.
Usuario A Usuario B
1. Lee el artculo 100. 1. Lee el artculo 200.2. Cambia el artculo 100. 2. Cambia el artculo 200.3. Escribe el artculo 100. 3. Escribe el artculo 200.
-
8/7/2019 IV Control De Transacciones
35/45
El CPU procesa lo del usuario A hasta que encuentra una
interrupcin de I/O o alguna otra causa de retraso. El S.O. cambia el
control al usuario B. El CPU procesa ahora lo del usuario B hasta que
encuentra una interrupcin; en este punto el S.O. pasa el control de
regreso al usuario A.
Orden de procesamiento en elServidor de la base de datos
1. Lee el artculo 100 para A.2. Lee el artculo 200 para B.3. Cambia el artculo 100 para A.4. Escribe el artculo 100 para A
5. Cambia el artculo 200 para B.6. Escribe el artculo 200 para B.
Problema de prdidas en la actualizacin.
El procesamiento concurrente del ejemplo anterior no tieneproblemas porque dos usuarios estn procesando datos diferentes.
Pero supongamos que ambos quieren procesar el artculo 100.
-
8/7/2019 IV Control De Transacciones
36/45
El usuario A lee el registro del artculo 100 en el rea de
trabajo de un usuario. De acuerdo con el registro, existen 10 unidades
en inventario. El usuario B lee el registro del artculo 100 en otra rea
de trabajo. Nuevamente, de acuerdo con el registro existen 10
unidades en inventario. Ahora el usuario A toma cinco, disminuye la
cantidad de elementos en su rea de trabajo a cinco y rescribe el
registro para el artculo 100. Luego el usuario B toma tres, disminuye
la cantidad en su rea de trabajo a siete, y rescribe el registro para el
elemento 100. La b.d. ahora muestra, incorrectamente, que existen
siete elementos en el inventario del elemento 100.
Nota: inventario en 10 elementos.
Usuario A Usuario B
1. Lee el artculo 100. 1. Lee el artculo 100.2. Reduce 5 artculos. 2. Reduce 3 artculos.3. Escribe el artculo 100. 3. Escribe el artculo 100.
Procesamiento del pedido en el servidor de la base de datos:
1. Lee el artculo 100 para A.2. Lee el artculo 100 para B.3. Establece que la cantidad de unidades es 5 para A.4. Escribe el artculo 100 para A.5. Establece que la cantidad de unidades es 7 para B.6. Escribe el artculo 100 para B.
En los pasos 3 y 4 se pierde el cambio y la escritura.
-
8/7/2019 IV Control De Transacciones
37/45
Como ya se menciono en la unidad pasada, a esta situacin se
le llama Actualizacin Perdida o Problema Concurrente en la
Actualizacin.
Una solucin para las inconsistencias causadas por
procesamiento concurrente es evitar que aplicaciones mltiples
obtengan copias de un mismo registro cuando va a tener cambios. A
esto se le denomina lock (bloqueo) de recursos (resource locking).
IV.12 LOCK DE RECURSOS.
Una manera de evitar problemas de procesamiento concurrente
es anular cualquier posibilidad de compartir informacin mediante el
lock de los datos que se recuperan para la actualizacin.
El siguiente ejemplo muestra el orden del procesamiento
usando un comando de lock (bloqueo):
Nota: inventario en 10 elementos.
Usuario A Usuario B
1. Aplica un lock al artculo 100. 1. Aplica un lock al artculo 100.2. Lee el artculo 100. 2. Lee el artculo 100.3. Reduce 5 artculos. 3. Reduce 3 artculos.4. Escribe el artculo 100. 4. Escribe el artculo 100.
Orden del procesamiento en el servidor de la base de datos:
1. Aplica un lock al artculo 100 para el usuario A.2. Lee el artculo 100 para A.3. Aplica un lock al artculo 100 para B; no se puede poner,
-
8/7/2019 IV Control De Transacciones
38/45
as que el usuario B entra en espera.4. Pone la cantidad de unidades igual a 5 para el usuario A.5. Escribe el artculo 100 para el usuario A.6. Libera el lock del usuario A en el artculo 100.7. Aplica un lock al artculo 100 para el usuario B.8. Lee el artculo 100 para B.
9. Pone la cantidad de unidades en 2 para el usuario B.10.Escribe el artculo 100 para B.11.Libera el lock del usuario B en el artculo 100.
Debido al bloqueo, la transaccin del usuario B debe esperar
hasta que el A haya terminado con los datos del artculo 100. Usando
esta estrategia, el B puede leer el registro del elemento 100 slo
despus de que el usuario A ha terminado la modificacin; la cantidad
final del artculo almacenado en la b.d. es dos.
Terminologa de locks.
Los locks se pueden poner ya sea en forma automtica, a
travs del SMBD, o mediante una instruccin enviada al SMBD desde el
programa de aplicacin, o a solicitud del usuario.
Los locks que impone el SMBD se llaman locks implcitos; los
que se ponen mediante una instruccin se llaman locks explcitos.
En el ejemplo anterior los locks se aplicaron en los renglones de
datos.
Algunos SMBD aplican locks por pgina, por tabla, o a toda la
b.d.; al tamao de un lock se le llama granularidad del bloqueo.
-
8/7/2019 IV Control De Transacciones
39/45
Los locks tambin varan en su tipo. Un lock exclusivo
impide el acceso a cualquier tipo de artculo. Ninguna otra transaccin
puede leer o cambiar los datos. Un lock compartido impide que se
hagan cambios al elemento de datos, pero permite la lectura. Es decir,
otras transacciones pueden leer de ese dato siempre y cuando no
intenten modificarlo.
Transacciones Serializables.
Cuando dos o ms transacciones se procesan al mismo tiempo,
los resultados en la b.d. deben ser lgicamente consistentes con los
resultados de las transacciones que hayan sido procesadas de manera
serial arbitraria. A un esquema para el procesamiento concurrente de
transacciones de le llama serializable.
La seriabilidad se puede alcanzar usando un lock de dos
fases; a las transacciones se les permite tener locks cuando sea
necesario, pero una vez que se libera el primer lock, no se puede
obtener otro. Las transacciones tienen una fase de crecimiento, en
la que los locks se pueden obtener, y una fase de liberacin en la que
se liberan los locks.
Deadlock (bloqueo Mortal).
-
8/7/2019 IV Control De Transacciones
40/45
Aun que los locks resuelven un problema, introducen otro, el
llamado Deadlock o Abrazo Mortal. En el siguiente cuadro se
muestra esta problemtica.
Usuario A Usuario B
1. Aplicar un lock al papel. 1. Aplicar un lock a los lpices.2. Tomar el papel. 2. Tomar los lpices.3. Aplicar un lock a los lpices. 3. Aplicar un lock al papel.
Orden del procesamiento en el servidor de la base de datos:
1. Aplicar un lock al papel para el usuario A.2. Aplicar un lock a los lpices para el usuario B.3. Procesar la solicitud del usuario A; escribir el registro del papel.4. Procesar la solicitud del usuario B; escribir el registro de los
lpices.5. Poner al usuario A en espera para los lpices.6. Poner al usuario B en espera para papel.
** BLOQUEADO **
El deadlock se puede evitar de varias maneras; una consiste en
permitir que los usuarios emitan slo una solicitud de lock a la vez.
En esencia, los usuarios deben bloquear al instante todos los recursos
que requieren.
En el ejemplo anterior, si el usuario A bloquea al principio los
recursos de papel y lpices el deadlock nunca tendr lugar.
-
8/7/2019 IV Control De Transacciones
41/45
Una segunda manera de evitar el deadlock es requerir que
todos los programas de aplicacin bloqueen los recursos en el mismo
orden. Incluso si no se bloquean todas las aplicaciones en ese orden,
el deadlock se reducir a los que lo hacen.
IV.13 BLOQUEO OPTIMISTA / BLOQUEO PESIMISTA.
Existen dos estilos bsicos de Bloqueos: Optimista y el
Pesimista.
Con el optimista se supone que no ocurrir ningn conflicto.
Los datos se leen, se procesan las transacciones y las actualizaciones y
despus se realiza una verificacin para ver si ocurre algn conflicto; en
caso contrario se termina la transaccin. Si hay un conflicto sta se
repite hasta que se procese sin ningn conflicto; como se muestra a
continuacin:
SELECT PRODUCTO.Nombre, PRODUCTO.CantidadFROM PRODUCTOWHERE PRODUCTO.Nombre=LpizViejaCantidad=PRODUCTO.CantidadSET NuevaCantidad=PRODUCTO.Cantidad 5
{procesar transaccin llevar a cabo accin de excepcin siNuevaCantidad
-
8/7/2019 IV Control De Transacciones
42/45
LOCK PRODUCTO
UPDATE PRODUCTOSET PRODUCTO.Cantidad=NuevaCantidadWHERE PRODUCTO.Nombre=Lpiz
AND PRODUCTO.Cantidad=ViejaCantidadUNLOCK PRODUCTO
{comprobar para ver si la actualizacin tuvo xito; de locontrario,
repetir la transaccin}
En esta secuencia se muestra un lock optimista; primero se
leen los datos y se almacena el valor real de Cantidadde lpices en la
variable ViejaCantidad; despus la transaccin se procesa y, suponiendo
que todo est bien, se aplica un lock en PRODUCTO; se emite una
instruccin SQL para actualizar el rengln lpiz con una condicin
WHERE con lo cual el valor actual de Cantidad sea igual a
ViejaCantidad. Si otra transaccin no ha cambiado la Cantidad delrengln lpiz, entonces UPDATE(actualizacin) tendr xito. Si otra
transaccin ha cambiado la Cantidaddel rengln lpiz, UPDATEfallar y
ser necesario repetir la transaccin.
El pesimista supone que ocurrir el conflicto. Primero se
aplican los locks, despus se procesa la transaccin y luego se liberan
los locks; como se muestra a continuacin:
LOCK PRODUCTO
SELECT PRODUCTO.Nombre, PRODUCTO.CantidadFROM PRODUCTOWHERE PRODUCTO.Nombre=LpizSET NuevaCantidad=PRODUCTO.Cantidad 5
-
8/7/2019 IV Control De Transacciones
43/45
{procesar transaccin llevar a cabo accin de excepcin siNuevaCantidad
-
8/7/2019 IV Control De Transacciones
44/45
IV.14 DECLARAR LAS CARACTERSTICAS DEL LOCK.
Las decisiones acerca de los tipos y estrategias de los locks se
han tenido que tomar a base de pruebas y errores; por tal, los
programas de aplicacin de base de datos, por lo general, no emiten
locks explcitos, sino que marcan las fronteras de la transaccin y
despus establecen el tipo de comportamiento de bloqueo que desean
use el SMBD. De esta manera, si se necesita cambiar el
comportamiento del bloqueo, no se necesita rescribir la aplicacin para
colocar locks en diferentes lugares en la transaccin. En lugar de eso,
se cambia la declaracin del lock.
A continuacin se muestra la transaccin de lpiz con las fronteras
de la transaccin marcadas con INICIAR TRANSACCIN, COMMIT
TRANSACCIN, ROLLBACK TRANSACCIN (BEGIN
TRANSACTION, COMMIT TRANSACTION y ROLLBAKC
TRANSACTION). Estas fronteras son la informacin esencial que el
SMBD necesita para aplicar las diferentes estrategias de bloqueo.
-
8/7/2019 IV Control De Transacciones
45/45
Si el programador declara que quiere que el lock sea optimista, el
SMBD establecer implcitamente los locks en los lugares correctos para
ese tipo de bloqueo; si mas tarde el programador cambia las tcticas y
solicita el bloqueo pesimista, el SMBD configurar implcitamente los
locks en un lugar diferente.
INICIAR TRANSACCIN:
SELECT PRODUCTO.Nombre, PRODUCTO.CantidadFROM PRODUCTOWHERE PRODUCTO.Nombre=LpizViejaCantidad=PRODUCTO.CantidadSET NuevaCantidad=PRODUCTO.Cantidad 5
{procesar transaccin llevar a cabo accin de excepcin siNuevaCantidad