Propiedades Fundamentales de las Transacciones (ACID)

Atomicidad: Una transacción es una unidad de trabajo indivisible; la totalidad de sus acciones son un éxito o un fracaso («todo o nada»).

Consistencia: Después de ejecutarse, una transacción debe dejar al sistema en un estado correcto o debe abortarlo. Si la transacción no puede alcanzar un estado final, debe regresar al sistema a su estado original.

Aislamiento: El comportamiento de una transacción no se ve afectado por el hecho de que otras transacciones puedan estar ejecutándose de manera concurrente; dicho de otra manera, una transacción no puede revelar sus resultados a otras transacciones concurrentes antes de su commit. La transacción debe serializar todos los accesos a recursos compartidos y garantizar que ningún programa concurrente interferirá con sus operaciones respectivas.

Durabilidad: Los efectos de una transacción son permanentes después de su grabación. Sus cambios deben sobrevivir a fallas del sistema (persistencia).

Gestión de Recuperación y Sincronización

La Bitácora

La operación ROLLBACK está basada en el uso de una bitácora. El DBMS (Sistema Manejador de Bases de Datos) mantiene una bitácora o diario en cinta o en disco (más comúnmente), en el cual se registran los detalles de todas las operaciones de actualización; en particular, los valores inicial y final del objeto modificado. Por tanto, si resulta necesario anular alguna modificación específica, el sistema puede utilizar la entrada correspondiente de la bitácora para restaurar el valor original del objeto restaurado.

Punto de Sincronización

Las operaciones COMMIT y ROLLBACK establecen lo que se conoce como punto de sincronización, lo cual representa el límite entre dos transacciones consecutivas, o el final de una unidad lógica de trabajo, y por tanto, el punto en el cual la base de datos está (o debería estar) en un estado de consistencia. Las únicas operaciones que establecen un punto de sincronización son COMMIT, ROLLBACK y el inicio de un programa. Cuando se establece un punto de sincronización:

• Se comprometen o anulan todas las modificaciones realizadas por el programa desde el punto de sincronización anterior.
• Se pierde todo posible posicionamiento en la base de datos.
• Se liberan todos los registros bloqueados.

Es importante advertir que COMMIT y ROLLBACK terminan la transacción, no el programa.

Tipos de Transacciones

Transacciones Simples Distribuidas

Una transacción simple puede correr en sitios múltiples y actualizar recursos localizados dentro de administradores de recursos múltiples.

Transacciones Encadenadas

Incluyen syncpoints, transacciones encadenadas y sagas:

• Syncpoint: Es un punto de sincronización que permite el guardado periódico del trabajo acumulado dentro de una transacción, permitiendo de esta forma dar marcha atrás al trabajo sin abortar la transacción. Sin embargo, este trabajo no es almacenado permanentemente, por lo que si el sistema se colapsa, el trabajo se pierde.
• Transacciones encadenadas: Son una variación de los syncpoints que convierten en durable el trabajo acumulado.
• Sagas: Extienden las transacciones encadenadas a fin de dar marcha atrás a una cadena entera si es necesario.

Transacciones Anidadas

Ofrecen la posibilidad de definir transacciones dentro de otras transacciones. Cada subtransacción puede emitir una grabación o retroceso para las piezas de trabajo asignadas.

Transacciones Simples

Todas las operaciones se llevan a cabo en el mismo nivel dentro de una transacción. La transacción empieza con un begin_transaction y termina ya sea con un commit_transaction o abort_transaction. Toda la transacción es indivisible. En un principio, las transacciones simples fueron suficientes por su sencillez y por su adaptación a operaciones bancarias breves. Actualmente, las transacciones han incursionado en todas las facetas de la computación, pero no han resultado lo más adecuado en ciertos escenarios, ya que tienen un comportamiento:

• Frágil: En transacciones de negocios que se extienden por períodos largos.
• Débil: En procesamiento por lotes.
• Nulo: En situaciones que requieren dar marcha atrás.

Una transacción simple no dura más de dos o tres segundos para evitar monopolizar recursos críticos del sistema, como candados sobre la base de datos. Así, los programas OLTP se dividen en transacciones breves ejecutadas una tras otra para producir resultados.

Monitores TP (Transaction Processing)

Un monitor de TP es un sistema operativo de procesamiento de transacciones que tiene como funciones principales:

Administración de Procesos

• Poner en marcha los procesos del servidor.
• Canalizar el trabajo en dirección a ellos.
• Vigilar su correcta ejecución.
• Equilibrar cargas de trabajo.

Administrador de Transacciones

Garantiza las propiedades ACID para todos los programas bajo su protección. Los monitores se especializan en la administración de transacciones desde su punto de origen (por lo general en el cliente) y a través de uno o más servidores, para luego volver al cliente originario.

Cuando una transacción llega a su fin, el monitor de TP debe cerciorarse de que todos los sistemas involucrados en ella queden en estado consistente. De esta forma, un monitor de TP sabe cómo correr transacciones, enrutarlas entre diferentes sistemas, equilibrar las cargas de ejecución y ponerlas nuevamente en marcha después de una falla. Todo esto sin importar los sistemas ni los administradores de recursos.

Arquitectura y Beneficios

Surgen de la necesidad de correr aplicaciones capaces de atender a cientos o miles de clientes, ya que los monitores permiten conectar en tiempo real a miles de usuarios que esperan un servicio sin necesidad de consumir tantos recursos. Por ejemplo: si un cliente necesita para ser atendido los siguientes recursos: 1 proceso, 1 conexión, ½ MB de RAM y una docena de archivos abiertos.

Cuando un cliente solicita un servicio, el monitor TP la destina a un proceso, el cual se enlaza con la función DLL llamada por el cliente, la invoca, supervisa su ejecución y regresa los resultados al cliente. Una vez concluido el trabajo, el proceso servidor regresa los resultados y el proceso puede ser reutilizado por otro cliente. El Sistema Operativo (SO) conserva en memoria las DLL para que puedan ser compartidas por otros procesos.

Si el número de solicitudes de clientes recibidas excede el número de procesos en el servidor, el monitor puede iniciar dinámicamente otros nuevos (equilibrio de cargas). Parte del equilibrio de cargas es la administración de prioridades en las solicitudes recibidas; de esta forma, solicitudes con prioridad alta se asignan a clases de servidor de alta prioridad. También el monitor de TP puede dividir sus clases de acuerdo al tipo de aplicación, tiempo de respuesta deseado, recursos que administran, requerimientos de tolerancia a fallas, etc. A un monitor de TP lo podemos ver como una arquitectura cliente/servidor compuesta de tres planos: una interfaz gráfica (GUI), la lógica de aplicación y los administradores de recursos.