Transacciones

Transacciones y Concurrencia

Lopez Mendoza Tania Guadalupe

Transacciones

¿Qué son las transacciones?

Es una propagación de uno o más cambios en la base de datos, ya sea cuando se crea, se modifica o se elimina un registro.Esta compuesta por varios procesos que se han de aplicar uno después del otro.

Propiedades de las transacciones ACID (Atomicity, Consistency, Isolation, Durability)

Aseguran que todas las operaciones dentro de la secuencia de trabajo se completen satisfactoriamen

Aseguran que la base de datos cambie estados en una transacción exitosa.

Atomicidad

Consistencia

Permiten que las operaciones sean aisladas y transparentes unas de otras.

Aseguran que el resultado o efecto de una transacción completada permanezca en caso de error del sistema

Aislamiento

Durabilidad

Estados de transacción

• Active: El estado inicial y permanece durante toda la ejecución
• Partially committed: Después de que se ha ejecutado el último statement (commit)
• Failed: Después de algun error, no se puede continuar
• Aborted: Se hace un "rollback" hacia un estado anterior consistente
• Committed: Después del éxito

Control de concurrencia

El control de accesos concurrentes y específicamente de transacciones concurrentes es manejado por un módulo del dbms llamado "scheduler"

Serial Schedules

Conflict-Serializability

Serializable Schedules

Todas las transacciones se ejecutan en serie una tras otra. En la programación serie, una transacción no inicia la ejecución hasta que la transacción que se está ejecutando actualmente finaliza la ejecución (no permite concurrencia)

Una programación se denomina conflicto serializable si se puede transformar en una programación serie intercambiando operaciones no conflictivas.

Un schedule puede ser serializable siempre y cuando se mantenga el mismo estado que si se tratase de un serial. (Permite la concurrencia)

Operaciones conflictivas:

Se dice que dos operaciones son conflictivas si se cumplen todas las condiciones:

• Pertenecen a diferentes transacciones
• Operan en el mismo elemento de datos
• Al menos uno de ellos es una operación de escritura

Procurando serializability con Locks

Locks Para garantizar que no haya problemas entre transacciones el scheduler emplea una tabla de lock para bloquear ciertas acciones de manera que es seguro ejecutar toda transacción.

La consistencia de transacciones se basa en que:

• Una transacción solo puede leer y escribir un elemento si se solicitó un bloqueo y éste no se ha liberado.
• Si una transacción bloquea un elemento, debe liberarlo posteriormente. Si un schedule cumple con las condiciones anteriores se dice que el schedule es "legal".

Two-phase locking (2PL)

"En toda transacción, todos los locks preceden a todos los unlocks".

El bloqueo de dos fases (2PL) es un método de control de concurrencia que divide la fase de ejecución de una transacción en tres partes.

• Asegura horarios serializables de conflicto.
• Si las operaciones de lectura y escritura introducen la primera operación de desbloqueo en la transacción, entonces se dice que es el protocolo de bloqueo de dos fases.

Shared y Exclusive Locks

• Un shared lock permite a otras transacciones leer la misma información pero no escribir
• Un exclusive lock evita que otros puedan leer y mucho menos escribir

Control de concurrencia por Timestamps

Timestamps

Dirty data

Dirty data se trata de información desactualizada, errónea, incompleta, no integrada, duplicada, entre otros

Es un tipo de dato que contiene una FECHA y una HORA en años, meses, días, horas, minutos, segundos y fracciones de un segundo. Para cada elemento afectado por la transacción se le asigna ese timestamp, de manera que se asegura que toda acción pertenece a dicha transacción.

Control de concurrencia por Validation

Scheduler mantiene un registro de lo que están haciendo las transacciones El proceso de toda transacción se divide en 3 fases: read, validate y write (leer, validar y escribir)

Fase de Escritura

Fase de Validación

Fase de Lectura

Se leen los valores de los diferentes datos y se almacenan en variables locales

Se analiza si una transacción “valida” y puede proceder sin violar serializabilidad. Si falla la transacción es abortada

Se aplican las actualizaciones reales a la base de datos. De lo contrario, la transacción retrocede.

Control de concurrencia en el DBMS

Manejo de transacciones en SQL

La transacción continua hasta que se realice un COMMIT o un ROLLBACK. Donde un commit actualizará Por default el modo de autocommit está encendido.

SET AUTOCOMMIT = 0 autocommit está en apagadado

Reactiva las transacciones automáticas para que el motor funcione como mejor lo pueda hacer cuando ejecutemos una sentencia SQL.

SET AUTOCOMMIT=1

Niveles de aislamiento en SQL

Los niveles de aislamiento de las transacciones especifican qué datos son visibles para las sentencias dentro de una transacción

READ UNCOMMITTED

READ COMMITTED

Evita las lecturas sucias al especificar que las sentencias no pueden leer valores de datos que hayan sido modificados pero que aún no hayan sido confirmados por otras

Tambíen llamado "dirty read" Significa que la base de datos debería poder leer el registro de la base de datos sin confirmar primero la transacción.

REPEATABLE READ

SERIALIZABLE

Impone una restricción adicional que se aplica cuando las mismas filas se leen varias veces durante el transcurso de la transacción. Así se garantiza que, cuando se lean posteriormente las mismas filas, sean iguales.

Todas las lecturas de la transacción solo ven datos confirmados antes de comenzar la transacción, y nunca ven los cambios de la transacción concurrente confirmados durante la ejecución de la transacción.

Consistent read

Significa que InnoDB utiliza su característica de multiversión para presentar a una consulta una captura de la base de datos en un momento determinado.

.Se utiliza un query ver los cabios hechos exactamente por aquellas transacciones que hicieron un "commit" antes de ese punto y no cambios hechos después ni mucho menos por transacciones "uncommited"

Next-key locking:

En bloqueos por renglón Innodb emplea un algoritmo llamado "next-key locking"Innodb hace el bloqueo de manera que busca o escanea el índice de una tabla, aplica bloqueos exclusivos o compartidos en los registros índice encontrados. De ahi que el bloque por renglón usualmente se conoce como bloqueos a los registros del índice.

Deadlock detection y rollback

Por lo general el dbms detecta aquellas transacciones que caen en un deadlock y lo que hacer es solucionarlo haciendo rollback considerando primero aquellas transacciones en las que tenga que "deshacer menos".

Locking and Indexes

Generalmente los bloqueos se hacen en los índices, de manera que hay ciertas variantes entre los distintos tipos.

GiST and R-tree indexes

B-tree indexes

Hash indexes

Bloqueos exclusivos o compartidos para R/W a nivel de índice Los bloqueos son liberados inmediatamente después de que cada comando es procesado

Bloqueos exclusivos o compartidos para R/W a nivel de página Los bloqueos son liberados inmediatamente después de que cada página es procesada

Bloqueos exclusivos o compartidos para R/W a nivel de página Los bloqueos son liberados inmediatamente después de que cada tupla es recuperada o insertada