IV Control De Transacciones

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.


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,


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.


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


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.


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);


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/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


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


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


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


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.


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:


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.


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


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,


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.


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


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,


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.


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


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.


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


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


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


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


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


t leer _ elemento(X);i X:= X+M;e escribir _ elemento(X); el elemento X tiene

unm leer _ elemento(Y); valor incorrecto,

porque


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


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.


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.


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);


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);


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


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.


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


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.


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.


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.


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,


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.


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).


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.


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


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


43/45



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.


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


IV Control De Transacciones

Documents

Transcript of IV Control De Transacciones