CONTROL DE CONCURRENCIA Y MANEJO DE

TRANSACCIONES

CONTROL DE CONCURRENCIA
Cuando varios usuarios intentan modificar datos al mismo tiempo, es
necesario establecer controles para impedir que las modificaciones de un
usuario influyan negativamente en las de otros. El sistema mediante el
cual se controla lo que sucede en esta situacin se denomina control de
concurrencia.
La Concurrencia en las base de datos es de suprema importancia en los
sistemas de informacin, ya que evita errores en el momento de
ejecutar las diferentes transacciones
En si la concurrencia es la propiedad de los sistemas que permiten que
mltiples procesos sean ejecutados al mismo tiempo, y que
potencialmente puedan interactuar entre s.

TIPOS DE CONTROL DE CONCURRENCIA

En general, existen tres formas comunes para administrar
concurrencia en una base de datos:

la

Control de concurrencia pesimista: una fila no est disponible

para los usuarios desde el momento en que se obtiene el registro
hasta que se actualiza en la base de datos.

Control de concurrencia optimista: una fila no est disponible

para otros usuarios mientras los datos se estn actualizando. La
actualizacin examina la fila de la base de datos y determina si se
han realizado cambios. Si se intenta actualizar un registro que ya se
ha modificado, se produce una infraccin de concurrencia.

"El ltimo gana": una fila no est disponible para otros usuarios
mientras los datos se estn actualizando. Sin embargo, no se intenta
comparar las actualizaciones con el registro original; simplemente, el

registro se escribe, con la posibilidad de sobrescribir los cambios

realizados por otros usuarios desde la ltima vez que se actualizaron
los registros.
Concurrencia pesimista
Normalmente, la concurrencia pesimista se utiliza por dos razones. En
primer lugar, a veces existe una gran contienda por los mismos
registros. El costo de bloquear los datos es menor que el de deshacer
los cambios cuando se producen conflictos de concurrencia.
La concurrencia pesimista es til tambin en situaciones en las que no
es conveniente que cambie el registro durante una transaccin. Un buen
ejemplo sera una aplicacin de inventario. Consideremos que el
representante de una compaa va a comprobar el inventario para un
posible cliente. Lo normal sera bloquear el registro hasta que se
generase un pedido, lo que, en lneas generales, identificara el artculo
con el estado de pedido y lo quitara del inventario disponible. Si no se
generase ningn pedido, el bloqueo se liberara para que otros usuarios
que comprobasen el inventario obtuviesen un recuento exacto del
inventario disponible.
No obstante, el control de concurrencia pesimista no es posible en una
arquitectura desconectada. Las conexiones se abren slo el tiempo
suficiente para leer los datos o actualizarlos, por lo que los bloqueos no
se pueden mantener durante perodos de tiempo prolongados. Adems,
una aplicacin que mantiene los bloqueos durante perodos de tiempo
prolongados no es escalable.
Concurrencia optimista
En la concurrencia optimista, los bloqueos se establecen y mantienen
slo mientras se est teniendo acceso a la base de datos. Los bloqueos
impiden que otros usuarios intenten actualizar registros en ese mismo
instante. Los datos estn siempre disponibles, excepto durante el
momento preciso en que est teniendo lugar una actualizacin. Para
obtener ms informacin, vea Simultaneidad optimista (ADO.NET).
Cuando se intenta realizar una actualizacin, se compara la versin
original de una fila modificada con la fila existente en la base de datos.
Si las dos son diferentes, la actualizacin no se realiza debido a un error
de concurrencia. En ese instante, es de su responsabilidad la
reconciliacin de las dos filas mediante su propia lgica de empresa.

El ltimo gana
Con la tcnica de "el ltimo gana", no se realiza ninguna comprobacin
de los datos originales y la actualizacin simplemente se escribe en la
base de datos. Es comprensible que se pueda producir el siguiente
escenario:
El usuario A obtiene un registro de la base de datos.
El usuario B obtiene el mismo registro de la base de datos, lo modifica y
devuelve a la base de datos el registro actualizado.
El usuario A modifica el registro "antiguo" y lo devuelve a la base de
datos.
En el escenario anterior, los cambios que realiz el usuario B no los ve
nunca el usuario A. Asegrese de que esta situacin sea aceptable si
tiene previsto usar el planteamiento "el ltimo gana" del control de
concurrencia.
TRANSACCIONES
Hasta ahora el modelo de operacin en la BD ha sido o de consultas, o
de modicaciones a la BD.
Hemos siempre supuesto que las acciones se ejecutan una a la vez y
que cada una se lleva a cabo completamente
Hemos supuesto que ni el software ni el hardware pueden fallar en el
intertanto de una operacin.
La vida real es muchsimo ms compleja...
No solo el hardware o el software pueden fallar dejando a la BD en un
estado inexplicable a partir de operaciones.
El sistema de base de datos normalmente est siendo accedido
simultneamente por muchos usuarios tanto para hacer consultas como
actualizaciones.

Algunas ejecuciones paralelas pueden intercalarse de manera tal de

dejar a la BD en un estado inconsistente.
SERIALIZACIN
Supongamos que en una aplicacin de reserva de pasajes para un vuelo
existe un procedimiento que:
busca un asiento libre
lo marca como ocupado
asigna el asiento al pasajero que ejecut la llamada
Es totalmente posible que al mismo tiempo dos pasajeros ejecuten el
procedimiento simultneamente y dejen la BD en un estado
indeseable.

Ambos pasajeros quedan con el mismo asiento asignado, la BD queda

en un estado indeseable.

Nos gustara que sea cual sea el orden de ejecucin, el estado de la BD

quedara como si se hubiese ejecutado un procedimiento primero y
luego el otro.
A esto se le llama una ejecucin serializable.

Si cualquier ejecucin de los procedimientos anteriores fue se

serializable entonces nunca se le asignara a dos pasajeros el mismo
asiento.
IMPORTANTE: NO queremos que los procedimientos siempre se
ejecuten uno tras otro, slo necesitamos que el resultado sea
serializable.

ATOMICIDAD
Supongamos que tenemos una aplicacin bancaria y un procedimiento
para transferir fondos entre las cuentas
A1 y A2:
1. Se verica que A1 tenga suciente dinero.
2. Se aumenta el saldo de A2 en el monto especicado.
3. Se disminuye el saldo de A1 en el monto especicado.
Supongamos que el sistema falla justo antes de comenzar a ejecutar la
lnea 3.
La BD queda en un estado indeseable (al menos para el banco).
En el ejemplo anterior nos gustara que las operaciones se ejecutaran
todas o que ninguna de ellas se ejecutara.
La ejecucin de una operacin es atmica si el estado de la BD luego de
la operacin es como si todos sus componentes se hubiesen ejecutado o
como si ninguno de ellos lo hubiese hecho.

TRANSACCIONES
Los problemas de serializacin y atomicidad pueden ser resueltos
usando transacciones.
Una transaccin est compuesta por un grupo de instrucciones de SQL
que se ejecutan atmicamente (se ejecutan todas o ninguna).

Por defecto adems, una transaccin exige ejecuciones serializables.

Las propiedades de las transacciones se las conoce como ACID: Atomicidad,
Coherencia, Aislamiento, Durabilidad.
Atomicidad: Una transaccin debe ser una unidad atmica de trabajo, o se
hace todo o no se hace nada.
Coherencia: Debe dejar los datos en un estado coherente luego de realizada
la transaccin.
Aislamiento: Las modificaciones realizadas por transacciones son tratadas en
forma independiente, como si fueran un solo y nico usuario de la base de
datos.
Durabilidad: Una vez concluida la transaccin sus efectos son permanentes y
no hay forma de deshacerlos.
COMO FUNCIONA UNA TRANSACCION

Una transaccin se comienza con una instruccin begin transaction

La instruccin commit termina la transaccin en forma exitosa y hace
permanente cualquier cambio realizado a la BD durante la transaccin.
Los cambios se hacen permanentes slo despus de un commit.
La instruccin rollback aborta la transaccin y la hace terminar en forma
no exitosa, cualquier cambio que la transaccin pudo hacer a la BD se
deshace.
ESTADOS DE TRANSACCIN
Una trancsaccion puede estar en uno de los siguientes estados:

Active, el estado inicial y permanece durante toda la ejecucin

Partially committed, despus de que se ha ejecutado el ltimo
statement
Failed, despus de algn error, no se puede continuar
Aborted, se hace un "rollback" hacia un estado anterior
consistente
Committed, despus del xito

TRANSACCIONES ABORTADAS
Una transaccin puede no llegar a su trmino debido a muchas razones:
situacin excepcional detectada que hace que el programa no pueda
continuar:

1.
2.
3.
4.
5.
6.

falla del programa

falla del software de BD
falla del Sistema Operativo
falla del hardware
falla de energa elctrica
control de concurrencia ha detectado un conicto

PASOS NECESARIOS PARA REALIZAR OPERACIONES A LA

BASE DE DATOS MEDIANTE TRANSACCIONES
Definir un objeto Transaction
Invocar el mtodo BeginTransaction
Incluir la lista de comandos sql en la transaccin mediante la
propiedad Transaction
Invocar el mtodo ExucuteNonquery para cada comando
Invocar el mtodo Commit
Si sucede una excepcin invocar el mtodo RollBack, esto se hace en
el bloque CATCH de un TRY