• Author / Uploaded
• Adrian Beat Box

Citation preview

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 situación se denomina control de concurrencia. La Concurrencia en las base de datos es de suprema importancia en los sistemas de información, 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 múltiples 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 estén actualizando. La actualización 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 infracción de concurrencia.



"El último gana": una fila no está disponible para otros usuarios mientras los datos se estén 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 también en situaciones en las que no es conveniente que cambie el registro durante una transacción. Un buen ejemplo sería una aplicación de inventario. Consideremos que el representante de una compañía va a comprobar el inventario para un posible cliente. Lo normal sería bloquear el registro hasta que se generase un pedido, lo que, en líneas generales, identificaría el artículo con el estado de pedido y lo quitaría del inventario disponible. Si no se generase ningún pedido, el bloqueo se liberaría 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 sólo el tiempo suficiente para leer los datos o actualizarlos, por lo que los bloqueos no se pueden mantener durante períodos de tiempo prolongados. Además, una aplicación que mantiene los bloqueos durante períodos de tiempo prolongados no es escalable. Concurrencia optimista En la concurrencia optimista, los bloqueos se establecen y mantienen sólo 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 están siempre disponibles, excepto durante el momento preciso en que está teniendo lugar una actualización. Para obtener más información, vea Simultaneidad optimista (ADO.NET). Cuando se intenta realizar una actualización, se compara la versión original de una fila modificada con la fila existente en la base de datos. Si las dos son diferentes, la actualización no se realiza debido a un error de concurrencia. En ese instante, es de su responsabilidad la reconciliación de las dos filas mediante su propia lógica de empresa.

El último gana Con la técnica de "el último gana", no se realiza ninguna comprobación de los datos originales y la actualización 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. Asegúrese de que esta situación sea aceptable si tiene previsto usar el planteamiento "el último gana" del control de concurrencia. TRANSACCIONES Hasta ahora el modelo de operación en la BD ha sido o de consultas, o de modificaciones 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 operación. La vida real es muchísimo más 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 simultáneamente 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. SERIALIZACIÓN Supongamos que en una aplicación 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 simultáneamente y dejen la BD en un estado “indeseable”.

Ambos pasajeros quedan con el mismo asiento asignado, la BD queda en un estado indeseable.

Nos gustaría que sea cual sea el orden de ejecución, el estado de la BD quedara “como si se hubiese” ejecutado un procedimiento primero y luego el otro. A esto se le llama una ejecución serializable.

Si cualquier ejecución de los procedimientos anteriores fue se serializable entonces nunca se le asignaría a dos pasajeros el mismo asiento. IMPORTANTE: NO queremos que los procedimientos siempre se ejecuten uno tras otro, sólo necesitamos que el resultado sea “serializable”.

ATOMICIDAD Supongamos que tenemos una aplicación bancaria y un procedimiento para transferir fondos entre las cuentas A1 y A2: 1. Se verifica que A1 tenga suficiente dinero. 2. Se aumenta el saldo de A2 en el monto especificado. 3. Se disminuye el saldo de A1 en el monto especificado. Supongamos que el sistema falla justo antes de comenzar a ejecutar la línea 3. La BD queda en un estado indeseable (al menos para el banco). En el ejemplo anterior nos gustaría que las operaciones se ejecutaran todas o que ninguna de ellas se ejecutara. La ejecución de una operación es atómica si el estado de la BD luego de la operación es como si todos sus componentes se hubiesen ejecutado o como si ninguno de ellos lo hubiese hecho.

TRANSACCIONES Los problemas de serialización y atomicidad pueden ser resueltos usando transacciones. Una transacción está compuesta por un grupo de instrucciones de SQL que se ejecutan atómicamente (se ejecutan todas o ninguna).

Por defecto además, una transacción exige ejecuciones serializables. Las propiedades de las transacciones se las conoce como ACID: Atomicidad, Coherencia, Aislamiento, Durabilidad. Atomicidad: Una transacción debe ser una unidad atómica de trabajo, o se hace todo o no se hace nada. Coherencia: Debe dejar los datos en un estado coherente luego de realizada la transacción. 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 transacción sus efectos son permanentes y no hay forma de deshacerlos. COMO FUNCIONA UNA TRANSACCION

Una transacción se comienza con una instrucción begin transaction La instrucción commit termina la transacción en forma exitosa y hace permanente cualquier cambio realizado a la BD durante la transacción. Los cambios se hacen permanentes sólo después de un commit. La instrucción rollback aborta la transacción y la hace terminar en forma no exitosa, cualquier cambio que la transacción pudo hacer a la BD se deshace. ESTADOS DE TRANSACCIÓN Una trancsaccion puede estar en uno de los siguientes estados:     

Active, el estado inicial y permanece durante toda la ejecución Partially committed, después de que se ha ejecutado el último statement Failed, después de algún error, no se puede continuar Aborted, se hace un "rollback" hacia un estado anterior consistente Committed, después del éxito

TRANSACCIONES ABORTADAS Una transacción puede no llegar a su término debido a muchas razones: situación 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 energía eléctrica control de concurrencia ha detectado un conflicto

PASOS NECESARIOS PARA REALIZAR OPERACIONES A LA BASE DE DATOS MEDIANTE TRANSACCIONES Definir un objeto Transaction Invocar el método BeginTransaction Incluir la lista de comandos sql en la transacción mediante la propiedad Transaction Invocar el método ExucuteNonquery para cada comando Invocar el método Commit Si sucede una excepción invocar el método RollBack, esto se hace en el bloque CATCH de un TRY