UNIDAD IV

CONTROL DE TRANSACCIONES

INTRODUCCIÓN.

Esta unidad trata de las transacciones, con las cuales se representa

una unidad lógica de procesamiento de b.d., además se analizarán la
problemática de los controles de concurrencia, y qué ocurre cuando
múltiples transacciones introducidas por varios usuarios se
interfieren 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 número

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 de

computadora al mismo tiempo se debe al concepto de
multiprogramación, que permite a la computadora procesar
simultáneamente varios programas o transacciones.
 Si sólo hay una unidad central de procesamiento (CPU), en
realidad sólo se puede procesar un programa a la vez. Sin embargo,
los sistemas operativos de multiprogramación 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 ejecución en el punto en el que se suspendió.

Así pues, la ejecución 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

simultánea

En la primera parte de la figura se muestra la ejecución

concurrente de dos programas A y B de manera intercalada. La
intercalación mantiene ocupada a la CPU cuando un programa en
ejecución requiere una operación de entrada o de salida (E/S), como
leer un bloque de un disco.

Si la computadora cuenta con múltiples procesadores (CPU) en

hw, es posible el procesamiento simultáneo de varios programas,
dando lugar a una concurrencia simultánea, no intercalada, como lo
ilustra la segunda parte de la grafica, con los programas C y D.
En un SGBD multiusuario, los elementos de información
almacenados son los recursos primarios a los que pueden tener acceso
concurrente los programas de usuarios, que constantemente obtienen
información de la b.d. y la modifican. A la ejecución de un programa
que lee o modifica el contenido de la b.d. es a lo que llamamos una
transacción.

IV. 2 OPERACIONES DE LECTURA Y ESCRITURA EN UNA

TRANSACCIÓN

Las operaciones de acceso a la b.d. que una transacción 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 básica de transferencia de datos del

disco a la memoria principal de la computadora.

Un elemento de información será un campo de algún registro

de la b.d., aunque puede ser una unidad mayor, como un registro o
incluso un bloque completo.
 La ejecución de una orden leer _ elemento(X) incluye los
siguientes pasos:

1. Encontrar la dirección 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 ejecución de una orden escribir _ elemento(X) incluye

los siguientes pasos:

1. Encontrar la dirección 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 algún 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 decisión sobre cuándo almacenar en disco un bloque
modificado que esté en un almacenamiento intermedio corresponde al
gestor de recuperación o el sistema operativo.

Para tener acceso a la b.d., una transacción deberá incluir

operaciones leer _ elemento y escribir _ elemento; en la siguiente figura
se muestran ejemplos de dos transacciones simples, (a) transacción T1
y (b) transacción 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 recuperación

se ocupan principalmente de las órdenes de acceso a la b.d. incluidas en
una transacción.

Las transacciones introducidas por los diversos usuarios se

podrían ejecutar de manera concurrente y podrían leer y actualizar los
mismos elementos de la b.d. Si esta ejecución concurrente no se
controla, puede provocar que la b.d. no sea consistente.
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 línea aérea, en la que se almacena un
registro por cada vuelo; cada registro incluye el número de asientos
reservados en ese vuelo, como elemento de información con nombre,
entre otra información.

La figura (a) muestra una transacción T1 que cancela N

reservas de un vuelo, cuyo número de asientos reservados está
almacenado en el elemento de la b.d. llamado X, y reserva el mismo
número de asientos (N) en otro vuelo cuyo número 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 transacción más simple, T2, que se

limita a reservar M asientos en el primer vuelo al que hace referencia la
transacción T1:

(b) leer _ elemento(X);

X:=X+M;
escribir _ elemento(X);
 Cabe aclarar que para este ejemplo, cuando se escribe un
programa para la b.d., tiene como parámetros los números de vuelos,
sus fechas y el número de asientos que se reservarán; por tanto, se
puede usar el mismo programa para ejecutar muchas transacciones,
cada uno con diferentes vuelos y números de asientos por reservar.

En lo que al control de concurrencia concierne, una transacción

es una ejecución específica de un programa sobre una fecha, un vuelo y
un número de asientos específicos.

En los ejemplos anteriores (a) y (b), las transacciones T1 y T2

son ejecuciones específicas de los programas que hacen referencia a los
vuelos específicos cuyos números de asientos están almacenados en los
elementos de información X y Y de la b.d.

Los tipos de problemas a los que podemos enfrentarnos con

este tipo de transacciones:

* Actualización 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 algún 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 actualizado que
resulta de T1:
 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,
porque
p escribir _ elemento(X); su actualización por
T1
o Y:= Y+N; se “perdió”
escribir _ elemento(Y);

(aplicar al ejemplo los siguientes valores: X=80 (originalmente había 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 problemática X=84, porque la actualización que
canceló cinco asientos se ha perdido.)

* Actualización Temporal:
La actualización temporal en algunas ocasiones llamada lectura
sucia, ocurre cuando una transacción actualiza un elemento de la b.d. y
luego la transacción falla por alguna razón:

T1 T2
leer _ elemento(X);
X:= X-N;
t escribir _ elemento(X);
i leer _ elemento(X);
e X:= X+M;
m escribir _ elemento(X);
p
o leer _ elemento(Y);

Otra transacción tiene acceso al elemento actualizado antes de

que se restaure a su valor original. Este ejemplo muestra que T1
actualiza el elemento X y después 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 transacción 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 transacción que no se completó ni se ha confirmado; por
ello, este problema se conoce también como problema de lectura
sucia.

* Resumen Incorrecto:
Si una transacción está calculando una función agregada de
resumen sobre varios registros mientras otras transacciones están
actualizando alguno de ellos, puede ser que la función agregada calcule
algunos valores antes de que se actualicen y otros después 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 después de
restarse
suma:=suma+X; N y lee Y antes de
sumarse N,
leer _ elemento(Y); así que el resultado es un
suma:=suma+Y; resumen incorrecto
leer _ elemento(Y);
Y:=Y+N;
escribir _ elemento(Y);

Por ejemplo, supongamos que una transacción T3 está

calculando el número total de reservas de todos los vuelos; mientras
tanto, se está ejecutando la transacción T1. Si ocurre la intercalación
de operaciones que se muestra en la figura anterior, el resultado de T3
será erróneo por una cantidad N porque T3 lee el valor de X después 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 RECUPERACIÓN.

Siempre que se introduce una transacción aun SGBD para

ejecutarla, el sistema tiene que asegurarse de que (a) todas las
operaciones de la transacción se completen con éxito y su efecto quede
asentado permanentemente en la b.d., o que (b) la transacción no
tenga efecto alguno sobre la b.d. ni sobre cualquier otra transacción.

El SGBD no debe permitir que se apliquen a la b.d. algunas

operaciones de una transacción T pero otras operaciones de T sí. Esto
puede suceder sí una transacción falla después de ejecutar algunas de
sus operaciones, pero antes de ejecutarlas todas.

Tipos de Fallos; hay varias razones por las que una transacción puede
fallar mientras se está ejecutando:

1. Fallo del HW y/o SW (caída): un error de hw o sw ocurre en el

sistema de cómputo durante la ejecución de una
transacción. Si el equipo falla, es posible que se pierda el
contenido de la memoria interna del computador.
2. Error de la transacción o del sistema: alguna operación de una
transacción puede hacer que ésta falle, (desbordamiento de
enteros o división entre cero, valores erróneos de los
parámetros o a un error lógico de programación, puede
 suceder que el usuario interrumpa a propósito la transacción
durante su ejecución).
3. Errores locales o condiciones de excepción detectadas por la
transacción: durante la ejecución de transacciones pueden
presentarse ciertas condiciones que requieran la cancelación
de la transacción; por ejemplo, es posible que no se
encuentren los datos para la transacción; una condición,
como un saldo insuficiente en una cuenta de una b.d.
bancaria, puede hacer que se cancele una transacción, como
un retiro de fondos de esa cuenta.
4. Imposición del control de concurrencia: el método de control
de concurrencia puede decidir que se aborte la transacción,
para reiniciarla después, 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 catástrofes físicos: esto se refiere a una
interminable lista de problemas que incluyen interrupción del
suministro de energía, 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 técnicas de control de concurrencia y de

recuperación de fallos, el concepto de transacción atómica es
fundamental.
IV.5 CONCEPTOS DE TRANSACCIONES Y SISTEMAS

La ejecución de un programa que incluye operaciones de

acceso a la b.d. se denomina transacción de b.d. o simplemente
transacción.

Una transacción es una unidad atómica de trabajo que se

realiza por completo o bien no se efectúa en absoluto.

En la mayoría de las aplicaciones de las b.d. los usuarios

transmiten su trabajo en forma de transacciones, que también se
conocen como Unidades Lógicas de Trabajo (LUWs, Logical Units of
Work).

Una transacción es una serie de acciones que llevarán a cabo

en la b.d., de tal manera que todas se ejecuten con éxito, o que ninguna
se realice por completo; en ese caso la b.d. permanecerá sin cambios.
Algunas veces esta transacción se llama atómica, puesto que se
ejecuta como una unidad.

Estados de las transacciones y operaciones adicionales.

Para fines de recuperación, el sistema necesita mantenerse al

tanto de cuánto la transacción se inicia, termina y se confirma o aborta.
Por lo tanto, el gestor de recuperación se mantiene al tanto de las
siguientes operaciones:
• INICIO_DE_TRANSACCION: ésta marca el principio de la
ejecución de la transacción.

• LEER o ESCRIBIR: éstas especifican operaciones de lectura o

escritura de elementos de la b.d. que se efectúan como parte de
una transacción.

• FIN_DE_TRANSACCIÓN: ésta especifica que las operaciones

de LEER y ESCRIBIR de la transacción han terminado y marca el
límite de la ejecución de la transacción. Sin embargo, en este
punto puede ser necesario verificar si los cambios introducidos
por la transacción se pueden aplicar permanentemente a la b.d.
(confirmar) o si la transacción debe abortarse porque viola el
control de concurrencia o por alguna otra razón.

• CONFIRMAR_TRANSACCIÓN: ésta señala que la transacción

terminó con éxito y que cualesquiera cambios (actualizaciones)
ejecutadas por ella se pueden confirmar sin peligro en la b.d. y
que no se cancelarán.

• REVERTIR (o ABORTAR): ésta indica que la transacción

término 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

operación y no a una transacción completa.
 • REHACER: ésta especifica que ciertas operaciones de
transacción se deben repetir (rehacer) para asegurar que todas
las operaciones de una transacción confirmada se hayan aplicado
con éxito a ala b.d.

LEER,
ESCRIBIR

INICIO_DE_ FIN_DE_
TRANSACCIÓN TRANSACCIÓN CONFIRMAR
ACTIVA PARCIALMENTE CONFIRMADA
CONFIRMADA

ABORTAR ABORTAR

FALLIDA
TERMINADA

La figura muestra un diagrama de transición de estados

que describe el paso de una transacción por sus estados de ejecución:

1) Una transacción entra en un estado activo inmediatamente

después de que inicia su ejecución, y ahí puede emitir

operaciones LEER y ESCRIBIR.

2) Cuando la transacción termina, pasa al estado parcialmente

confirmado; en este punto, algunas técnicas de control de
concurrencia requieren que se efectúen ciertas verificaciones
para garantizar que la transacción no interfiere otras
transacciones en ejecución. Algunos protocolos de
recuperación deben asegurar que un fallo del sistema no
provocará una incapacidad para registrar permanentemente los
 cambios hechos por la transacción (usualmente asentando los
cambios en una bitácora del sistema).

3) Una vez realizadas con éxito ambas verificaciones, se dice que la

transacción ha llegado a su punto de confirmación y pasa al
estado confirmado. Una vez que una transacción está en el
estado confirmado, ha concluido con éxito su ejecución.

4) Sin embargo, una transacción puede pasar al estado fallido si

una de las verificaciones falla o si la transacción se aborta
mientras está en el estado activo. En tal caso, es posible que
la transacción 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 transacción. Las transacciones fallidas o abortadas
pueden reiniciarse posteriormente, ya sea en forma automática
o después de reintroducirse como transacciones nuevas.

Bitácora del sistema.

Para poderse recuperar de los fallos de transacciones, el

sistema mantiene una bitácora (diario) que sigue la pista a todas las
operaciones de transacciones que afectan los valores de elementos de la
b.d.

La bitácora se mantiene en disco, de modo que no la afecta

ningún tipo de fallo, más que los de disco o los catastróficos. Además,
la bitácora se respalda periódicamente en cinta para protegerse contra
estos tipos de fallos.

A continuación se mencionan los tipos de entradas que se

escriben en la bitácora y la acción que realiza cada una de ellas. En
estas entradas, T se refiere a un identificador de transacción único que
el sistema genera automáticamente y que sirve para identificar cada
transacción:

[inicio_de_transacción, T]: asienta que se ha iniciado la

ejecución de la transacción T.
[escribir_elemento, T, X, valor_anterior, nuevo_valor]: asienta
e la transacción T cambió el valor del elemento de
d. X de valor_anterior a nuevo_valor.
3. [leer_elemento, T, X]: asienta que la transacción T leyó el
lor del elemento de b.d. X.
4. [confirmar, T]: asienta que la transacción 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 transacción T.

Si se supone que todos los cambios permanentes de la b.d.

ocurren dentro de las transacciones, entonces la noción de recuperarse
de una transacción equivale a deshacer o rehacer las operaciones
recuperables individualmente a partir de la bitácora.

Si el sistema se cae, podemos recuperar la b.d. a un estado

consistente examinando la bitácora y usando técnicas de recuperación.
 Dado que la bitácora contiene un registro de cada operación
ESCRIBIR que altera el valor de algún elemento de la b.d., es posible
deshacer (cancelar) el efecto de estas operaciones ESCRIBIR de una
transacción T rastreando hacia atrás en la bitácora y restableciendo
todos los elementos alterados con una operación ESCRIBIR de T a su
valor_anterior.

También podemos rehacer el efecto de las operaciones

ESCRIBIR de una transacción T rastreando hacia delante en la bitácora y
cambiando todos los elementos modificados por una operación
ESCRIBIR de T a su nuevo_valor.

Punto de confirmación de una transacción.

Una transacción T llega a su punto de confirmación 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
bitácora, es decir, que la transacción está confirmada, y se supone que
su efecto se asentó permanentemente en la b.d. En ese momento la
transacción escribe una entrada [confirmar, T] en la bitácora.

Si ocurre un fallo del sistema, buscamos en la bitácora todas las

transacciones T que han escrito una entrada [inicio_de_transacción, T]
en la bitácora pero no han escrito todavía su entrada [confirmar, T]; es
posible que durante el proceso de recuperación estas transacciones
tengan que revertirse para cancelar su efecto sobre la b.d. Las
transacciones que ya escribieron su entrada de confirmación en la
bitácora también deberán haber asentado en ella todas sus operaciones
ESCRIBIR, pues de lo contrario no estarían confirmadas; su efecto sobre
la b.d. puede rehacerse a partir de las entradas de la bitácora.

El archivo de la bitácora debe mantenerse en disco; por lo que la

actualización 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 bitácora
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
añade una entrada; esto ahorra el gasto extra de escribir varias veces
en el disco el mismo bloque de archivo. Cuando se cae el sistema,
sólo las entradas de bitácora que se han escrito en disco se considera
que están en el proceso de recuperación, porque pueden haberse
perdido el contenido de la memoria principal.

Por ello, antes de que una transacción llegue a su punto de

confirmación, cualquier porción de la bitácora que no se haya escrito en
el disco todavía se deberá grabar. Este proceso se denomina forzar la
escritura del archivo de bitácora antes de confirmar una transacción.

Puntos de control en la bitácora del sistema.

Otro tipo de entrada en la bitácora es el llamado punto de control.

Un registro [punto_de_control] se escribe en la bitácora periódicamente
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,
todas las transacciones que tengan sus entradas [confirmar,T] en la
bitácora antes de una entrada [punto_de_control] no necesitarán la
repetición de sus operaciones ESCRIBIR en caso de una caída del
sistema.
El gestor de recuperación 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 número t de transacciones
confirmadas desde el último punto de control, donde los valores de m o
de t son parámetros del sistema.

El asentamiento de un punto de control consiste en las siguientes

acciones:
1 Suspender temporalmente la ejecución de las transacciones.
2 Forzar la escritura de todas las operaciones de actualización
pertenecientes a transacciones confirmadas del
almacenamiento intermedio al disco.
3 Escribir un registro [punto_de_control] en la bitácora y forzar
la escritura de la bitácora en el disco.
4 Reanudar la ejecución de transacciones.

Un registro de punto de control en la bitácora también puede incluir

información adicional, como una lista de identificadores de las
transacciones activas o las ubicaciones (direcciones) del primer registro
y del más reciente (último) en la bitácora para cada transacción activa.
Esto puede facilitar la anulación de operaciones en caso de ser necesaria
la reversión de una transacción.
IV.6 PROPIEDADES DESEABLES EN LAS TRANSACCIONES.

Las transacciones atómicas deben poseer varias propiedades.

Éstas se conocen como propiedades ACID (Atomic, Consistent,
Insolated y Durable), y deben ser impuestas por los métodos de control
de concurrencia y de recuperación del SGBD:

- Atomicidad: Una transacción es una unidad de procesamiento;

o bien se realiza por completo o no se realiza en absoluto.
- Conservación de la consistencia: Una ejecución correcta de
la transacción debe llevar a la b.d. de un estado consistente a
otro.
- Aislamiento: Unas transacción 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 actualización temporal
y hace innecesaria las reversiones en cascada de las
transacciones.
- Durabilidad o permanencia: Una vez que una transacción
ha modificado la b.d. y las modificaciones se han confirmado,
éstas nunca deben perderse por un fallo subsecuente.

Es obligación del método recuperación garantizar la atomicidad.

Si por alguna razón una transacción no puede completarse, como por
una caída del sistema ala mitad de su ejecución, el método de
recuperación debe cancelar todos los efectos de la transacción sobre la
b.d.

Se considera que la propiedad de conservación de la

consistencia es responsabilidad de los programadores que escriben los
programas de b.d. o del módulo de SGBD que impone las restricciones
de integridad. Recuerde que un estado de la b.d. es una colección de
todos los elementos de información (valores) almacenados en la b.d. en
un momento dado. Un estado consistente de la b.d. satisface las
restricciones especificadas en el esquema, además 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 transacción, estará en un estado
consistente después de la ejecución completa de la transacción,
suponiendo que no hay interferencias con otras transacciones.

IV.7 TRANSACCIONES CONSISTENTES.

Como se acaba de leer, una transacción atómica es aquella en

la que todas las acciones de la b.d. pueden ocurrir, o también ninguna.
Una transacción 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 transacción es durable, el SMBD
proporcionará las facilidades para recuperar los cambios de todas las
acciones confirmadas cuando sea necesario.
 Sin embargo, los términos consistentes y aislados no son tan
definitivos como atómicos y durables. Considere la siguiente
instrucción de actualización de SQL:

UPDATE CLIENTE
SET CódigodeÁrea = ‘425’
WHERE CódigoPostal = ‘98050’

Suponga que hay 500,000 tuplas en la tabla CLIENTE y que

500 tienen CódigoPostal igual a ‘98050’; le tomará algún tiempo al
SMBD encontrar las 500 tuplas, durante ese tiempo, ¿Otras
transacciones permitirán actualizar los campos de CódigodeÁrea o
CódigoPostal de CLIENTE? Si la instrucción de SQL es consistente,
estas actualizaciones estarán prohibidas. La actualización 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 Instrucción.

Ahora considere una transacción que contenga dos

instrucciones de actualización de SQL:

BEGIN TRANSACTION
UPDATE CLIENTE
SET CódigoÁrea = ‘425’
WHERE CódigoPostal = ‘98050’

(Otra transacción en funcionamiento)

UPDATE CLIENTE
 SET Descuento = 0.05
WHERE CódigoÁrea = ‘425’
(Otra transacción en funcionamiento)

COMMIT TRANSACTION
En este contexto, ¿qué significa consistente? La
consistencia del nivel de instrucción que quiere decir que cada
instrucción 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 transacción significa que todos las tuplas impactadas
por cualquiera de las instrucciones SQL son protegidos de cambios
durante la transacción completa. Observe, sin embargo, que para
algunas implementaciones de la consistencia del nivel de transacción,
una transacción no verá sus propios cambios. En este ejemplo, la
segunda instrucción SQL puede no ver los cambios en las tuplas
derivadas de la primera instrucción SQL.

Así, que se debe tener cuidado o poner más atención para

determinar qué tipo de consistencia se refiere, así como, de no caer en
la trampa potencial de consistencia del nivel de transacción. El
término aislada, se considera a continuación.

IV.8 NIVEL DE AISLAMIENTO DE LA TRANSACCIÓN.

Los locks evitan que los procesos concurrentes ocasionen la

pérdida de actualizaciones; pero hay otro tipo de problemas que no
evitan. Específicamente, ocurre una lectura sucia cuando una
transacción lee un registro cambiado que no ha sido registrado en la
base de datos. Por ejemplo, esto puede ocurrir si una transacción lee
un renglón cambiado por una segunda transacción no confirmada, la
cual más tarde aborta.

Las lecturas no repetibles ocurren cuando una transacción relee

datos que fueron leídos con anterioridad y encuentra modificaciones o
eliminaciones ocasionadas por una transacción confirmada. Por último,
las lecturas fantasmas tienen lugar cuando una transacción relee los
datos y encuentra que se insertaron nuevos renglones como resultado
de una transacción confirmada en la lectura anterior.

El estándar ANSI SQL de 1992 define cuatro niveles de

aislamiento, que especifican cuál de estos problemas se permite que
ocurra. El objetivo es que el programador de la aplicación pueda
declarar el tipo de nivel de aislamiento que quiere y entonces tener la
administración 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 están prohibidas. El nivel de
aislamiento de lecturas repetibles prohíbe 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 más restrictivo, de no menor

rendimiento efectivo, depende mucho de la carga de trabajo y de cómo
estén escritos los programas de aplicación. Además, no todos los
 productos SMBD usan todos estos niveles. Los productos también
varían en la manera en la cual se manejan y en cuanto a la carga que
ponen en el programador de la aplicación.

NIVEL DE AISLAMIENTO

Lectura Lectura Lectura

No Confirmada Confirmada Repetible Serializable

Lectura Sucia Posible No Posible No Posible No Posible

Tipo
De Lec. No Repetible Posible Posible No Posible No Posible
Problema
Lectura Fantasma Posible Posible Posible No Posible

IV.9 PLANES Y RECUPERABILIDAD

Cuando varias transacciones se ejecutan de manera

concurrente e intercalada, el orden de ejecución 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
restricción de que, para cada transacción Ti que participe en P, las
operaciones de Ti en P deben aparecer en el mismo orden en que
ocurren en Ti.
 Para fines de recuperación 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 notación abreviada para escribir un plan emplea los
siguientes símbolos:

Leer _ elemento ( l ) Confirmar ( c )

Escribir _ elemento ( e ) Abortar ( a )

A esta notación se le añade como subíndice el identificador de

la transacción (número de la transacción) a cada operación del Plan.
En esta notación, el elemento de la b.d. que se lee o escribe, X, sigue a
las operaciones l y e entre paréntesis.

Por ejemplo, el plan de las figuras (a) y (b), que llamaremos P a,

se puede escribir como sigue después de añadirle las operaciones de
confirmación:

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
un
m leer _ elemento(Y); valor incorrecto,
porque
 p escribir _ elemento(X); su actualización
por T1
o Y:= Y+N; se “perdió”
escribir _ 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);
p
o leer _ elemento(Y);

la transacción T1 falla y debe volver el valor

de X a su antiguo valor; mientras tanto T2 ha
leído el valor “temporal” incorrecto de X.

Se dice que dos operaciones de un plan están 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) están 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 están en conflicto porque son operaciones
de lectura; y las operaciones e2 (X) y e1 (Y) tampoco están en conflicto,
porque operan sobre diferentes elementos de información, X e Y.
 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 operación de confirmar o de abortar como
última operación de cada transacción en el plan.
2. Para cualquier par de operaciones de la misma transacción Ti, su
orden de aparición en P es el mismo que su orden de aparición
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 estén en conflicto ocurran en el plan sin definir cuál lo haga primero,
dando lugar a la definición 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
(condición 3) y para cualquier par de operaciones de la misma
transacción (condición 2); y la condición 1 simplemente dice que todas
las operaciones en las transacciones deben aparecer en el plan
completo. Puesto que toda transacción ha sido confirmada o abortada,
un plan completo nunca contendrá transacciones activas.
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 intercalación, sólo hay dos formas posibles

de ordenar las operaciones de las dos transacciones para su ejecución:

1. Ejecutar todas las operaciones de la transacción T1 (en orden)

seguidas de todas las operaciones de la transacción T2 (en
orden).

Plan a)

T1 T2
leer_elemento (X);
X:=X-N;
escribir_elemento(X);
leer_elemento (Y);
 Y:=Y+N;
escribir_elemento (Y);
leer_elemento(X);
X:=X+M;
escribir_elemento(X);

2. Ejecutar todas las operaciones de la transacción T2 (en orden)

seguidas de todas las operaciones de la transacción 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 intercalación de operaciones, habrá muchos

órdenes posibles en que el sistema podrá ejecutar las operaciones
individuales de las transacciones. Dos posibles planes se ilustran a
continuación:

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);
 Y:=Y+N;
escribir_elemento (Y);

Plan d)

T1 T2
leer_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 teoría de la seriabilidad, con la que se intenta determinar
cuáles planes son “correctos” y cuáles no, e inventar técnicas que sólo
permitan planes correctos.

Planes en serie, no en serie y seriables por conflictos.

Un plan P es en serie si, por cada transacción 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 suposición 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 razón es que
suponemos que toda transacción es correcta si se ejecuta por sí sola, y
que las transacciones son independientes entre sí; por ello, no importa
cuál transacción se ejecute primero. En tanto toda transacción 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

intercalación de las operaciones; es decir, si en un plan en serie, una
transacción está esperando que se complete una operación de E/S, no
podremos conmutar el procesador a otra transacción, desperdiciándose
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 actualización perdida al
obtener X = 92 y Y =93; esto es, la transacción T2 lee el valor de X antes
de que la transacción T1 lo modifique, así que sólo 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 cuáles de los planes no en

serie siempre dan un resultado correcto y cuáles pueden dar resultados
erróneos; es decir, el concepto con el que se caracterizan los planes de
esta manera es el de la seriabilidad de un plan.
 Un plan P de n transacciones es seriable si es equivalente a
algún 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 definición

más 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 más seguro y general para definir la equivalencia de

dos planes consiste en no hacer suposición 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 información afectados por los planes se deben aplicar a
ese elemento en el mismo orden en ambos planes. Por lo regular se
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 simultánea, esto no puede ser verdad, ya que el
CPU de la máquina que está procesando la b.d. sólo puede ejecutar una
instrucción a la vez.

Por lo general las transacciones están 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 artículo 100. 1. Lee el artículo 200.
2. Cambia el artículo 100. 2. Cambia el artículo 200.
3. Escribe el artículo 100. 3. Escribe el artículo 200.
 El CPU procesa lo del usuario A hasta que encuentra una
interrupción 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 interrupción; en este punto el S.O. pasa el control de
regreso al usuario A.

Orden de procesamiento en el
Servidor de la base de datos

1. Lee el artículo 100 para A.

2. Lee el artículo 200 para B.
3. Cambia el artículo 100 para A.
4. Escribe el artículo 100 para A
5. Cambia el artículo 200 para B.
6. Escribe el artículo 200 para B.

Problema de pérdidas en la actualización.

El procesamiento concurrente del ejemplo anterior no tiene

problemas porque dos usuarios están procesando datos diferentes.
Pero supongamos que ambos quieren procesar el artículo 100.
 El usuario A lee el registro del artículo 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 artículo 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 artículo 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 artículo 100. 1. Lee el artículo 100.
2. Reduce 5 artículos. 2. Reduce 3 artículos.
3. Escribe el artículo 100. 3. Escribe el artículo 100.

Procesamiento del pedido en el servidor de la base de datos:

1. Lee el artículo 100 para A.

2. Lee el artículo 100 para B.
3. Establece que la cantidad de unidades es 5 para A.
4. Escribe el artículo 100 para A.
5. Establece que la cantidad de unidades es 7 para B.
6. Escribe el artículo 100 para B.

En los pasos 3 y 4 se pierde el cambio y la escritura.

 Como ya se menciono en la unidad pasada, a esta situación se
le llama Actualización Perdida o Problema Concurrente en la
Actualización.

Una solución para las inconsistencias causadas por

procesamiento concurrente es evitar que aplicaciones múltiples
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 información mediante el
lock de los datos que se recuperan para la actualización.

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 artículo 100. 1. Aplica un lock al artículo 100.
2. Lee el artículo 100. 2. Lee el artículo 100.
3. Reduce 5 artículos. 3. Reduce 3 artículos.
4. Escribe el artículo 100. 4. Escribe el artículo 100.

Orden del procesamiento en el servidor de la base de datos:

1. Aplica un lock al artículo 100 para el usuario A.

2. Lee el artículo 100 para A.
3. Aplica un lock al artículo 100 para B; no se puede poner,
 así que el usuario B entra en espera.
4. Pone la cantidad de unidades igual a 5 para el usuario A.
5. Escribe el artículo 100 para el usuario A.
6. Libera el lock del usuario A en el artículo 100.
7. Aplica un lock al artículo 100 para el usuario B.
8. Lee el artículo 100 para B.
9. Pone la cantidad de unidades en 2 para el usuario B.
10.Escribe el artículo 100 para B.
11.Libera el lock del usuario B en el artículo 100.

Debido al bloqueo, la transacción del usuario B debe esperar

hasta que el A haya terminado con los datos del artículo 100. Usando
esta estrategia, el B puede leer el registro del elemento 100 sólo
después de que el usuario A ha terminado la modificación; la cantidad
final del artículo almacenado en la b.d. es dos.

Terminología de locks.

Los locks se pueden poner ya sea en forma automática, a

través del SMBD, o mediante una instrucción enviada al SMBD desde el
programa de aplicación, o a solicitud del usuario.

Los locks que impone el SMBD se llaman locks implícitos; los

que se ponen mediante una instrucción se llaman locks explícitos.

En el ejemplo anterior los locks se aplicaron en los renglones de

datos.

Algunos SMBD aplican locks por página, por tabla, o a toda la

b.d.; al tamaño de un lock se le llama granularidad del bloqueo.
 Los locks también varían en su tipo. Un lock exclusivo
impide el acceso a cualquier tipo de artículo. Ninguna otra transacción
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 más transacciones se procesan al mismo tiempo,

los resultados en la b.d. deben ser lógicamente 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 liberación en la que
se liberan los locks.

Deadlock (bloqueo Mortal).

 Aun que los locks resuelven un problema, introducen otro, el
llamado Deadlock o Abrazo Mortal. En el siguiente cuadro se
muestra esta problemática.

Usuario A Usuario B
1. Aplicar un lock al papel. 1. Aplicar un lock a los lápices.
2. Tomar el papel. 2. Tomar los lápices.
3. Aplicar un lock a los lápices. 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 lápices 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
lápices.
5. Poner al usuario A en espera para los lápices.
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 sólo 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 lápices el deadlock nunca tendrá lugar.
 Una segunda manera de evitar el deadlock es requerir que
todos los programas de aplicación 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 básicos de Bloqueos: Optimista y el

Pesimista.

Con el optimista se supone que no ocurrirá ningún conflicto.

Los datos se leen, se procesan las transacciones y las actualizaciones y
después se realiza una verificación para ver si ocurre algún conflicto; en
caso contrario se termina la transacción. Si hay un conflicto ésta se
repite hasta que se procese sin ningún conflicto; como se muestra a
continuación:

SELECT PRODUCTO.Nombre, PRODUCTO.Cantidad

FROM PRODUCTO
WHERE PRODUCTO.Nombre=’Lápiz’
ViejaCantidad=PRODUCTO.Cantidad
SET NuevaCantidad=PRODUCTO.Cantidad – 5

{procesar transacción – llevar a cabo acción de excepción si

NuevaCantidad<0, etc., Suponer que todo está BIEN}
 LOCK PRODUCTO

UPDATE PRODUCTO
SET PRODUCTO.Cantidad=NuevaCantidad
WHERE PRODUCTO.Nombre=’Lápiz’
AND PRODUCTO.Cantidad=ViejaCantidad

UNLOCK PRODUCTO

{comprobar para ver si la actualización tuvo éxito; de lo

contrario,
repetir la transacción}

En esta secuencia se muestra un lock optimista; primero se

leen los datos y se almacena el valor real de Cantidad de lápices en la
variable ViejaCantidad; después la transacción se procesa y, suponiendo
que todo está bien, se aplica un lock en PRODUCTO; se emite una
instrucción SQL para actualizar el renglón lápiz con una condición
WHERE con lo cual el valor actual de Cantidad sea igual a
ViejaCantidad. Si otra transacción no ha cambiado la Cantidad del
renglón lápiz, entonces UPDATE (actualización) tendrá éxito. Si otra
transacción ha cambiado la Cantidad del renglón lápiz, UPDATE fallará y
será necesario repetir la transacción.

El pesimista supone que ocurrirá el conflicto. Primero se

aplican los locks, después se procesa la transacción y luego se liberan
los locks; como se muestra a continuación:

LOCK PRODUCTO

SELECT PRODUCTO.Nombre, PRODUCTO.Cantidad

FROM PRODUCTO
WHERE PRODUCTO.Nombre=’Lápiz’
SET NuevaCantidad=PRODUCTO.Cantidad – 5
 {procesar transacción – llevar a cabo acción de excepción si
NuevaCantidad<0, etc., Suponer que todo está BIEN}

UPDATE PRODUCTO
SET PRODUCTO.Cantidad=NuevaCantidad
WHERE PRODUCTO.Nombre=’Lápiz’

UNLOCK PRODUCTO

{no se necesita comprobar si la actualización tuvo éxito}

Aquí, se aplica un lock en PRODUCTO antes de iniciar

cualquier trabajo. Los valores se leen, la transacción se procesa,
ocurre el UPDATE y PRODUCTO se desbloquea.

La ventaja del lock optimista es que se obtiene sólo después de

que la transacción ha sido procesada. Así, el lock se mantiene durante
menos tiempo que con el lock pesimista. Si la transacción es
complicada, o si el cliente es lento, el lock se mantendrá durante un
tiempo considerablemente menor. Esta ventaja será aún más
importante si la granularidad del lock es grande; por ejemplo la tabla
PRODUCTO.

La desventaja del lock optimista es que si existe mucha

actividad en el renglón lápiz (por ejemplo), la transacción se puede
repetir muchas veces. Así, las transacciones que implican mucha
actividad en un renglón determinado son muy poco adecuadas para el
lock optimista.
IV.14 DECLARAR LAS CARACTERÍSTICAS 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 aplicación de base de datos, por lo general, no emiten
locks explícitos, sino que marcan las fronteras de la transacción y
después 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 aplicación para
colocar locks en diferentes lugares en la transacción. En lugar de eso,
se cambia la declaración del lock.

A continuación se muestra la transacción de lápiz con las fronteras

de la transacción marcadas con INICIAR TRANSACCIÓN, COMMIT
TRANSACCIÓN, ROLLBACK TRANSACCIÓN (BEGIN
TRANSACTION, COMMIT TRANSACTION y ROLLBAKC
TRANSACTION). Estas fronteras son la información esencial que el
SMBD necesita para aplicar las diferentes estrategias de bloqueo.
 Si el programador declara que quiere que el lock sea optimista, el
SMBD establecerá implícitamente los locks en los lugares correctos para
ese tipo de bloqueo; si mas tarde el programador cambia las tácticas y
solicita el bloqueo pesimista, el SMBD configurará implícitamente los
locks en un lugar diferente.

INICIAR TRANSACCIÓN:

SELECT PRODUCTO.Nombre, PRODUCTO.Cantidad

FROM PRODUCTO
WHERE PRODUCTO.Nombre=’Lápiz’
ViejaCantidad=PRODUCTO.Cantidad
SET NuevaCantidad=PRODUCTO.Cantidad – 5

{procesar transacción – llevar a cabo acción de excepción si

NuevaCantidad<0,
etc.}

UPDATE PRODUCTO
SET PRODUCTO.Cantidad=NuevaCantidad
WHERE PRODUCTO.Nombre=’Lápiz’

{continuar procesando transacciones}….

Si la transacción ha terminado normalmente THEN (ENTONCES)

COMMIT TRANSACCIÓN

ELSE (DE OTRO MODO)

ROLLBACK TRANSACCIÓN

END IF (TERMINA SI)

Continuar procesando otras acciones que no son parte de esta

transacción…