¿Qué es el procesamiento de transacciones ejemplo? ¿Qué es el sistema de procesamiento de transacciones? ¿Qué es un proceso transaccional? ¿Dónde se utiliza el sistema de procesamiento de transacciones?

Procesamiento de transacciones

Se llama transacción a una colección de operaciones que forman una única unidad lógica de trabajo. Es una unidad de la ejecución de un programa que accede y posiblemente actualiza varios elementos de datos A nivel hardware, transcurren en diferentes tiempos, pero un sistema de base de datos debe asegurar que la ejecución de las transacciones se realice adecuadamente a pesar de la existencia de fallos (o se ejecuta la transacción completa o no se ejecuta en absoluto).

La meta de las transacciones es asegurar que todos los objetos gestionados por un servidor permanecen en un estado consistente cuando dichos objetos son accedidos por múltiples transacciones y en presencia de caídas del servidor.

Propiedades ACID

Para asegurar la integridad de los datos se necesita que el sistema de base de datos mantenga las siguientes propiedades de las transacciones, denominadas propiedades ACID, acrónimo que se obtiene de las iniciales de cada una de las propiedades en inglés:

Toda planificación secuencial en cuanto a conflictos es también secuencial en cuanto a vistas, pero no ocurre lo mismo a la inversa (la secuencialidad en cuanto a conflictos es más restrictiva).

Recuperabilidad

Una planificación es recuperable cuando se puede deshacer (hacer ROLLBACK) cualquiera de sus transacciones. Permite resolver los problemas que ocurren cuando una de las transacciones concurrentes falla.

La recuperabilidad se basa en determinar en qué momentos se puede comprometer una transacción y cuándo es posible hacer ROLLBACK. No se fija en la cuestión de la secuencialidad.

Las planificaciones recuperables pueden ser de dos formas:

Es deseable evitar el retroceso en cascada, ya que provoca un aumento significativo del trabajo necesario para deshacer cálculos.

La recuperabilidad busca que las transacciones puedan hacer ROLLBACK en algún momento y que eso se pueda resolver sin tener que deshacer otras transacciones involucradas. Es la forma de prevenir la lectura sucia (dependencia no confirmada) de datos.

Esquemas de control de concurrencia

Cuando se ejecutan varias transacciones concurrentemente en la base de datos, puede que deje de conservarse la propiedad de aislamiento. Es necesario que el sistema controle la interacción entre las transacciones concurrentes; dicho control se lleva a cabo a través de uno de los muchos mecanismos existentes llamado esquema de control de concurrencia.

Protocolos basados en el bloqueo

Una forma de asegurar la secuencialidad es exigir que el acceso a los elementos de datos se haga en exclusión mutua; es decir, mientras una transacción accede a un elemento de datos, ninguna otra transacción puede modificar dicho elemento. El método más habitual que se usa para implementar este requisito es permitir que una transacción acceda a un elemento de datos sólo si posee actualmente un bloqueo sobre dicho elemento.

Los protocolos de control de concurrencia basados en el bloqueo se basan en el bloqueo de datos. Para poder hacerlo, se requiere un componente adicional del SGBD que se encargue de los bloqueos, utilizándolos o negándole: es el gestor de control de concurrencia.

Existen dos tipos de bloqueos:

Es necesario que toda transacción solicite un bloqueo del modo apropiado sobre un elemento de datos dependiendo de los tipos de operaciones que se vayan a realizar sobre el mismo. La petición se hace al gestor de control de concurrencia. La transacción puede realizar la operación sólo después de que el gestor de control de concurrencia conceda el bloqueo a la transacción.

Los bloqueos son compatibles unos con otros solamente en el caso en el que dos transacciones estén pidiendo un bloqueo compartido. En ese caso, ambas transacciones pueden leer el dato, pero ninguna otra transacción podrá escribir en él. Para que otra transacción pueda escribir ese dato, tiene que esperar a que el mismo se desbloquee (soltar el bloqueo). Lo mismo ocurre si una transacción tiene el bloqueo exclusivo: aquellas que pidan otro bloqueo exclusivo o compartido sobre el mismo dato deben esperar a que se suelte el bloqueo. Es importante tener en cuenta que el orden de las operaciones en una transacción nunca se altera: una transacción no puede hacer otras tareas mientras espera a que se suelte un bloqueo.

Cuando una transacción solicita un bloqueo de un modo particular sobre un elemento de datos y ninguna otra transacción posee un bloqueo sobre el mismo elemento de datos en un modo conflictivo, se puede conceder el bloqueo. Sin embargo, esto puede causar un fenómeno denominado inanición (livelock/starvation): ocurre cuando una transacción T1 tiene un bloqueo compartido sobre un dato mientras otra transacción T2 espera a que se le dé un bloqueo exclusivo sobre el mismo; paralelamente otra transacción T3 pide bloqueo compartido sobre ese dato y el gestor se lo otorga porque son bloqueos compatibles. Aunque T1 suelte el bloqueo, T2 debe seguir esperando su bloqueo exclusivo porque ahora el bloqueo compartido lo tiene T3. Si otra transacción T4 solicita un bloqueo compartido, lo obtiene y aunque T3 suelte el bloqueo, T2 sigue esperando. Como T2 nunca puede acceder al dato, se ve obligada a hacer ROLLBACK por inanición: agotó el tiempo máximo durante el cual podía esperar a que se le otorgue un bloqueo (time out). En este caso, la inanición puede resolverse agregando una condición, como puede ser denegar la solicitud de bloqueo compartido de T3 porque la petición de bloqueo exclusivo de T2 ocurrió antes.

Si no se otorga un bloqueo sobre un dato, la transacción que lo solicita debe esperar a que la transacción que posee en ese momento dicho bloqueo lo suelte. Esto es porque se apunta a la secuencialidad: la posibilidad de esperar asegura que la transacción solicitante vino después de aquella que obtuvo el bloqueo primero. Una transacción que obtuvo un bloqueo antes que otra es la que se ejecutaría primero en una planificación secuencial.

Cuanto antes se desbloquee un dato, más "rápido" va a funcionar el procesamiento de transacciones porque, en esquemas de alta concurrencia, las otras transacciones en ejecución van a esperar menos para acceder a ese dato.

Sin embargo, existen desventajas al desbloquear un dato demasiado rápido:

Protocolo de bloqueo de 2 fases

El protocolo de bloqueo en 2 fases es un esquema de control de concurrencia que busca evitar este problema. Este protocolo exige que cada transacción realice las peticiones de bloqueo y desbloqueo de dos fases: en la fase de crecimiento la transacción debe pedir todos los bloqueos que necesita, lo que hace que aumente la cantidad de bloqueos, pero no puede liberarlos. El punto de la planificación en el cual la transacción obtiene su bloqueo final (el final de la fase de crecimiento) es el punto de bloqueo: en este punto, la transacción tiene todos los bloqueos que necesita y puede realizar todas sus operaciones. Recién ahí empieza a desbloquear todos los datos en la fase de decrecimiento y lo hace hasta que se compromete, pero en esta etapa no puede realizar más peticiones de bloqueo y, por ende, no obtendrá nuevos bloqueos.

Este esquema es secuencial en cuanto a conflictos: las planificaciones que se realicen bajo este esquema van a ser equivalentes a planificaciones secuenciales en donde aquellas transacciones que llegaron antes a su punto de bloqueo van antes en un esquema secuencial. Es decir, el orden de las transacciones va a estar dado por su punto de bloqueo. Esto soluciona el problema de la lectura no repetible. Pero puede haber deadlocks.

Sin embargo, este esquema no resuelve la posibilidad del retroceso en cascada. Por eso se trabaja con versiones menos flexibles de este protocolo.

Estos esquemas solucionan la posibilidad de retroceso en cascada ya que ninguna transacción podrá leer un dato modificado por otra transacción hasta que esta última se comprometa.

Protocolo de bloqueo de 2 fases con intención de bloqueo

El protocolo de bloqueo de 2 fases con intención de bloqueo está basado no solamente en el bloqueo, sino también en la granularidad: divide la base de datos en zonas (tablas), éstas se subdividen en archivos (bloques/páginas) y finalmente, estos últimos se dividen en registros. Permite obtener no sólo un bloqueo sobre un elemento de datos, sino que también pueden bloquearse tablas, archivos e incluso toda la base de datos.

En función de esto, pueden identificarse bloqueos implícitos y explícitos: al pedir un bloqueo (exclusivo o compartido) sobre la base, una tabla o un archivo (bloqueo explícito) quedan implícitamente bloqueados los niveles inferiores que dependen del elemento bloqueado.

El problema es que, al momento de pedir un bloqueo, hay que verificar todos los nodos (superiores e inferiores) para chequear que no haya otros bloqueos que impidan la concesión del que se está solicitando. Para resolver esto es que se añade la intención de bloqueo: si un nodo se bloquea en modo intencional se está haciendo un bloqueo explícito en un nivel inferior del árbol. Se piden bloqueos intencionales sobre los niveles superiores al elemento que se quiere bloquear. Demuestran la intención de bloquear de forma exclusiva o compartida un nodo jerárquicamente inferior. Una transacción que quiera bloquear un nodo debe recorrer el camino en el árbol desde la raíz hasta dicho nodo. Durante el recorrido del árbol la transacción bloquea los distintos nodos en un modo intencional.

Tipo de bloqueo

Permite…

Exclusivo (X)

Leer y escribir el nodo o los nodos inferiores.

Compartido (C)

Leer los nodos inferiores.

Intencional compartido (IC)

Permite pedir bloqueo IC o C en un nodo inferior.

Intencional exclusivo (IX)

Permite pedir bloqueo IX o X en un nodo inferior.

Intencional exclusivo y compartido (IXC)

Es una combinación de bloqueo IX con bloqueo C, por lo que permite pedir bloqueo IX o X en un nodo inferior y leer los nodos inferiores. Pide bloqueos para leer varios nodos, pero escribir solamente en uno o algunos.

El protocolo de bloqueo de 2 fases con intención de bloqueo asegura la secuencialidad en cuanto a conflictos. Cada transacción Tx puede bloquear un nodo Q usando las reglas siguientes:

  1. Debe observar la compatibilidad de los bloqueos, ya que en función de ellos se otorgará (o no) el bloqueo solicitado.
  2. Debe bloquear la raíz del árbol en primer lugar y puede bloquearla de cualquier modo.
  3. Puede bloquear un nodo Q en modo C o IC sólo si está bloqueando actualmente al padre de Q en modo IX o IC.
  4. Puede bloquear un nodo Q en modo X, IXC o IX sólo si está bloqueando actualmente al padre de Q en modo IX o IXC.
  5. Puede bloquear un nodo sólo si no ha desbloqueado previamente ningún nodo (porque Tx es de dos fases).
  6. Puede desbloquear un nodo Q sólo si no ha bloqueado a ninguno de los hijos de Q.

En este protocolo es necesario que se adquieran los bloqueos en orden descendente (de la raíz a las hojas), y que se liberen en orden ascendente (de las hojas a la raíz).

Esquemas multiversión (marcas temporales)

Los esquemas de control de concurrencia basados en bloqueos aseguran la secuencialidad, o bien retrasando una operación, o bien abortando la transacción que realiza la operación. Esto podría evitarse si se mantuvieran en el sistema copias anteriores de cada elemento de datos.

En los esquemas de control de concurrencia multiversión, cada operación de escritura crea una nueva versión del dato. Cuando se realiza una operación de lectura, el gestor de control de concurrencia elige una de las versiones del dato que se va a leer, asegurando que dicha elección se haga de tal manera que asegure la secuencialidad. Un bloqueo impediría que una transacción lea un dato que haya sido modificado por otra hasta que esta última suelte el bloqueo. Trabajar con varias versiones permite que la transacción que necesita el dato pueda leer la versión anterior del mismo para asegurar la secuencialidad.

Ordenación por marcas temporales multiversión

En el esquema de ordenación de marcas temporales multiversión cada transacción tiene asignada una marca temporal (MT) antes de que comience su ejecución:

Las marcas temporales pueden implementarse a través de un reloj o un contador lógico. Esto permite saber el orden de cada una en el plan de ejecución, de acuerdo con la siguiente regla:

Si MTTx

Es por esto que la marca temporal implica la secuencialidad de las transacciones.

Cada versión de un dato va a tener los siguientes elementos:

Lo que ocurra al ejecutar una transacción dependerá de la operación que intente llevar a cabo y el valor de sus marcas temporales:

Sea Qk la versión de QUE con MTEQk≤MTTx

Si Tx ejecuta la operación de leer Q

Si Tx ejecuta la operación de escribir Q

Si una transacción Tx quiere leer un dato, lee la versión de ese dato con la mayor marca temporal de creación que sea anterior a la marca temporal de Tx. Tiene que ser la MT de escritura mayor de las menores a la MT de la transacción que quiere leer.

MTE(Q)

Si una transacción Tx quiere escribir un dato y su MT es inferior a la MT de la última transacción Ty que leyó el dato, Tx tiene que hacer ROLLBACK. Al volverse a ejecutar, la MT de Tx y pasa a ser mayor a la de Ty. Es la única manera de asegurar la secuencialidad:

Si MTTx

Esta regla fuerza a que se aborte una transacción que realice una escritura “demasiado tarde”. Con más precisión, si Tx intenta escribir una versión que alguna otra transacción

haya leído, entonces no se puede permitir que dicha escritura tenga éxito.

Si MTTx

Si MTTx>MTLQk y MTTx>MTEQk Creación de una nueva versión de Qk

Ventajas

Desventajas

  • Asegura la secuencialidad.
  • Las peticiones de lectura no fallan y no tienen que esperar porque no se trabaja con bloqueos.
  • Las lecturas requieren actualizar el campo MTLT, lo que implica un acceso extra al disco.
  • Los conflictos se resuelven por medio de retrocesos.
  • Hay probabilidad de planificaciones no recuperables y retrocesos en cascada.
  • Bloqueo de 2 fases multiversión

    El esquema de bloqueo de 2 fases multiversión funciona distinto para transacciones de sólo lectura que para transacciones de actualización (escritura). En este caso, la marca temporal siempre es un contador (no puede ser un reloj). Cada valor de un dato sólo tiene una marca temporal.

    Las transacciones de actualización realizan un bloqueo de dos fases riguroso; es decir, mantienen todos los bloqueos hasta el final de la transacción. Así, se pueden secuenciar según su orden de terminación. No tienen una marca temporal asignada cuando se crean. Las transacciones de lectura sí tienen marca temporal asignada cuando se crean, al valor del contador, y para realizar las lecturas siguen el protocolo de ordenación por marcas temporales multiversión.

    Si una transacción Tx de lectura quiere leer un dato, lee la mayor versión de ese mismo dato que tenga una marca temporal inferior a la de Tx, igual que en el esquema anterior. Sin embargo, lo diferente en este protocolo es que a las transacciones de actualización sólo se les asigna una marca temporal cuando se comprometen. Esto es porque el bloqueo de 2 fases que se usa es el riguroso, en donde el momento del compromiso de la transacción determina el momento en el que se ejecutarán en una planificación secuencial. Por eso, recibe como valor de marca temporal el momento en el que se compromete. Esto implica que, cuando una transacción de actualización escribe un dato, se le asigna temporalmente el valor máximo de marca temporal posible: así ninguna transacción de lectura la puede leer hasta que la transacción de actualización se comprometa (porque su valor de marca temporal nunca va a ser superior al máximo). Cuando la transacción de actualización se compromete, aumenta el valor del contador en 1 y asigna ese nuevo valor del contador a los datos que tenían ese valor de marca temporal máximo. De esta forma sólo se leerán los datos escritos por transacciones de actualización ya comprometidas, porque las nuevas transacciones de lectura tendrán un valor de marca temporal mayor que el de la última transacción de actualización comprometida.

    Si una transacción de actualización Tx quiere leer un dato, siempre lee la versión más reciente del mismo porque no tiene marca temporal (existe en el tiempo cuando se compromete). Si otra transacción de actualización Ty quiere leer ese mismo dato no puede porque Tx obtuvo un bloqueo exclusivo sobre dicho dato para poder escribirlo (y aún no se comprometió). Por lo tanto, Ty tiene que esperar. Tx tendrá el bloqueo hasta que se comprometa: cuando esto pase ahí cambiará su valor de marca temporal y recién ahí Ty puede pedir su bloqueo.

    Transacciones de sólo lectura

    Transacciones de actualización

    Tx ejecuta la operación de leer Q

    Si Tx ejecuta la operación de leer Q

    Si Tx ejecuta la operación de escribir Q

    Se muestra el contenido de la versión más reciente de Q:

    MT(Q)

    Tx obtiene un bloqueo compartido sobre Q, leyendo la versión más reciente de ese dato.

    Tx obtiene un bloqueo exclusivo sobre Q, creando una nueva versión de ese dato.

    Al comprometerse Tx: