4 Concurrencia

4.
CONCURRENCIA
4.1 Conceptos
4.2 Propiedades de las transacciones
4.3 Grados de consistencia
4.4 Niveles de aislamiento
4.5 Commit y rollback
CONCEPTOS
No se puede hablar de Concurrencias en Base de datos sin el uso de las Transacciones. se
ejecutan serialmente, una después de la otra, sin ninguna intercalación. Informalmente, una
transacción es la ejecución de ciertas instrucciones que acceden a una base de datos
compartida.
Se llama Transacción a una colección de operaciones que forman una unidad lógica de trabajo
en una BD realizada por una o más sentencias SQL estrechamente relacionadas.
PROPIEDADES DE LAS
TRANSACCIONES
Una unidad lógica de trabajo debe exhibir cuatro propiedades, conocidas como propiedades
ACID (atomicidad, coherencia, aislamiento y durabilidad), para ser calificada como
transacción.
Atomicity: siginifica que el sistema permite operaciones atómicas. Una operación
atómica es aquella que si está formada por operaciones más pequeñas, se
consideran como un paquete indivisible. Deben ejecutarse todas correctamente,
o en el caso de que alguna de ellas no pueda hacerlo, el efecto de las que ya se
han ejecutado no debe hacerse notar, debe deshacerse, como si el conjunto de
las operaciones no se hubieran realizado.
No obstante, atomicidad y transacción no son sinónimos. Mientras atomicidad es
una propiedad, la transacción es el mecanismo que utilizan los SGBD para lograr
la atomicidad.
Begin Transaction - Programa - End Transaction
Responsable: El método de recuperación, de no completar todas las
operaciones, devuelve la BD a su estado anterior a empezar esa Tx rollback).
Coherencia: Asegura que cualquier transacción llevará a la base de datos de
un estado válido a otro estado válido.
Después de terminar una transacción la Base de datos no viola ninguna de

sus reglas: valores obligatorios, claves únicas, etc.
Responsable: los programadores mediante la definición adecuada de la

integridad referencial: check, triggers, primary key, foreign key,…
Aislamiento: Los efectos de una Tx no son visibles a otros usuarios mientras no se
confirmen.
Una transacción en ejecución no puede revelar sus resultados a otras transacciones
concurrentes antes de finalizar.
Más aun, si varias transacciones, se ejecutan concurrentemente, los resultados
deben ser los mismos que si ellas se hubieran ejecutado secuencialmente. Esto se
conoce como seriabilidad debido a que su resultado es la capacidad de volver a
cargar los datos iniciales y reproducir una serie de transacciones para finalizar con
los datos en el mismo estado en que estaban después de realizar transacciones
originales.
Responsable: el método de concurrencia: mecanismos, reglas, protocolos
Durabilidad: Significa que en el mismo momento en que una operación ha
terminado satisfactoriamente y el sistema informa de ello, sus efectos quedan
ya registrados permanentemente. Si el sistema falla no debe permitir que se
pierdan las operaciones realizadas por Tx ya confirmadas.
Responsable: el método o gestor de recuperación.

GRADOS DE CONSISTENCIA
Consistencia es un término más amplio que el de integridad. Podría definirse como la
coherencia entre todos los datos de la base de datos. Cuando se pierde la integridad
también se pierde la consistencia. Pero la consistencia también puede perderse por
razones de funcionamiento.
Una transacción finalizada (confirmada parcialmente) puede no confirmarse
definitivamente (consistencia).
Si se confirma definitivamente el sistema asegura la persistencia de los cambios que
ha efectuado en la base de datos.
Si se anula los cambios que ha efectuado son deshechos.
La ejecución de una transacción debe conducir a un estado de la base de datos consistente (que
cumple todas las restricciones de integridad definidas).
Si se confirma definitivamente el sistema asegura la persistencia de los cambios que ha
efectuado en la base de datos.
Si se anula los cambios que ha efectuado son deshechos.
Una transacción que termina con éxito se dice que está comprometida (commited), una
transacción que haya sido comprometida llevará a la base de datos a un nuevo estado
consistente que debe permanecer incluso si hay un fallo en el sistema. En cualquier momento
una transacción sólo puede estar en uno de los siguientes estados.
Activa (Active): el estado inicial; la transacción permanece en este estado durante su
ejecución.
Parcialmente comprometida (Uncommited): Después de ejecutarse la última transacción.
Fallida (Failed): tras descubrir que no se puede continuar la ejecución normal.
Abortada (Rolled Back): después de haber retrocedido la transacción y restablecido la base de
datos a su estado anterior al comienzo de la transacción.
Comprometida (Commited): tras completarse con éxito.
Aspectos relacionados al procesamiento de transacciones
Los siguientes son los aspectos más importantes relacionados con el procesamiento de transacciones:
Modelo de estructura de transacciones. Es importante considerar si las transacciones son planas o pueden estar
anidadas.
Consistencia de la base de datos interna. Los algoritmos de control de datos semántico tienen que satisfacer siempre
las restricciones de integridad cuando una transacción pretende hacer un commit.
Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir medios de comunicación entre los
diferentes nodos de una red para garantizar la atomicidad y durabilidad de las transacciones. Así también, se requieren
protocolos para la recuperación local y para efectuar los compromisos (commit) globales.
Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia deben sincronizar la ejecución de
transacciones concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el
aislamiento de las mismas.
Protocolos de control de réplicas. El control de réplicas se refiere a cómo garantizar la consistencia mutua de datos
replicados. Por ejemplo se puede seguir la estrategia read-one-write-all (ROWA).
NIVELES DE AISLAMIENTO
Las transacciones especifican un nivel de aislamiento que define el grado en que se
debe aislar una transacción de las modificaciones de recursos o datos realizadas por
otras transacciones. Los niveles de aislamiento se describen en cuanto a los efectos
secundarios de la simultaneidad que se permiten, como las lecturas desfasadas o
ficticias.
Control de los niveles de aislamiento de transacción:
Controla si se realizan bloqueos cuando se leen los datos y qué tipos de bloqueos se
solicitan.
Duración de los bloqueos de lectura.
Si una operación de lectura que hace referencia a filas modificadas por otra
transacción:
Se bloquea hasta que se libera el bloqueo exclusivo de la fila.

Recupera la versión confirmada de la fila que existía en el momento en el que
empezó la instrucción o la transacción.
Lee la modificación de los datos no confirmados.
El nivel de aislamiento para una sesión SQL establece el comportamiento de los bloqueos para
las instrucciones SQL.
El estándar ANSI/ISO SQL define cuatro niveles de aislamiento transaccional en función de
tres eventos que son permitidos o no dependiendo del nivel de aislamiento. Estos eventos son:
Lectura sucia. Las sentencias SELECT son ejecutadas sin realizar bloqueos, pero podría
usarse una versión anterior de un registro. Por lo tanto, las lecturas no son consistentes al usar
este nivel de aislamiento.
Lectura norepetible. Una transacción vuelve a leer datos que previamente había leído y
encuentra que han sido modificados o eliminados por una transacción cursada.
Lectura fantasma. Una transacción vuelve a ejecutar una consulta, devolviendo un conjuto de
registros que satisfacen una condición de búsqueda y encuentra que otros registro que
satisfacen la condición han sido insertadas por otra transacción cursada.
Los niveles de aislamiento SQL son definidos basados en si ellos permiten a cada uno de los
eventos definidos anteriormente. Es interesante notar que el estándar SQL no impone un
esquema de cierre específico o confiere por mandato comportamientos particulares, pero más
bien describe estos niveles de aislamiento en términos de estos teniendo muchos mecanismos
de cierre/coincidencia, que dependen del evento de lectura.
COMMIT Y ROLLBACK
Estructura de una transacción

Una transacción de base de datos consta de una o más instrucciones.
Específicamente, una transacción consiste en una de las siguientes:
•Una o más sentencias DML que en conjunto constituyen un cambio atómica a la

base de datos
•Una declaración DML
Una transacción tiene un principio y un final.
Inicio de una transacción
Una transacción comienza cuando se encuentra la primera sentencia de SQL
ejecutable.
Una sentencia de SQL ejecutable es una instrucción SQL que genera llamadas a una
instancia de base de datos, incluyendo DML y DDL y la instrucción SET
TRANSACCIÓN.
Final de una transacción
• Una transacción termina cuando se produce alguna de las siguientes acciones: Un usuario
emite una sentencia COMMIT -guardar- o ROLLBACK -deshacer- sin una cláusula
SAVEPOINT -punto de restauración.
• Mediante COMMIT, un usuario solicita explícitamente o implícitamente que los cambios
en la transacción sean permanentes. Los cambios realizados por la transacción son
permanentes y visibles para otros usuarios sólo después de una transacción.
• Un usuario ejecuta una sentencia DDL como CREATE, DROP, RENAMEZ o ALTER.
•La base de datos emite una sentencia COMMIT implícito antes y después de cada
instrucción DDL. Si la transacción actual contiene instrucciones DML, a continuación,
Oracle Database primera confirma la transacción y luego corre y se compromete la
sentencia DDL como una nueva, transacción de un único estado.
•Un usuario sale normalmente de la mayoría de las utilidades y herramientas de base de
datos Oracle, haciendo que la transacción actual que se ha comprometido de forma
implícita. El comportamiento AUTOCOMMIT cuando un usuario se desconecta
depende de la aplicación y la configuración del gestor
http://www.prograweb.com.mx/tallerBD/0405COMMIT_y_ROLLBACK.php

4 Concurrencia

Cargado por

Copyright:

Formatos disponibles

4 Concurrencia

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

4 Concurrencia

Cargado por

Copyright:

Formatos disponibles

4.

Después de terminar una transacción la Base de datos no viola ninguna de

Responsable: los programadores mediante la definición adecuada de la

Responsable: el método o gestor de recuperación.

Se bloquea hasta que se libera el bloqueo exclusivo de la fila.

Estructura de una transacción

•Una o más sentencias DML que en conjunto constituyen un cambio atómica a la

También podría gustarte