Sistema de procesamiento de transacciones

Un sistema de procesamiento de transacciones (TPS por sus siglas en ingls) es un tipo de sistema de informacin. Un TPS recolecta, almacena, modifica y recupera toda la informacin generada por las transacciones producidas en una organizacin. Una transaccin es un evento que genera o modifica los datos que se encuentran eventualmente almacenados en un sistema de informacin. Para que un sistema informtico pueda ser considerado como un TPS, este debe superar el test ACID. Desde un punto de vista tcnico, un TPS monitoriza los programas transaccionales (un tipo especial de programas). La base de un programa transaccional est en que gestiona los datos de forma que estos deben ser siempre consistentes (por ejemplo, si se realiza un pago con una tarjeta electrnica, la cantidad de dinero de la cuenta sobre la que realiza el cargo debe disminuir en la misma cantidad que la cuenta que recibe el pago, de no ser as, ninguna de las dos cuentas se modificar), si durante el transcurso de una transaccin ocurriese algn error, el TPS debe poder deshacer las operaciones realizadas hasta ese instante. Si bien este tipo de integridad es que debe presentar cualquier operacin de procesamiento de transacciones por lotes, es particularmente importante para el procesamiento de transacciones on-line: si, por ejemplo, un sistema de reserva de billetes de una lnea area es utilizado simultneamente por varios operadores, tras encontrar un asiento vaco, los datos sobre la reserva de dicho asiento deben ser bloqueados hasta que la reserva se realice, de no ser as, otro operador podra tener la impresin de que dicho asiento est libre cuando en realidad est siendo reservado en ese mismo instante. Sin las debidas precauciones, en una transaccin podra ocurrir una reserva doble. Otra funcin de los monitores de transacciones es la deteccin y resolucin de interbloqueos (deadlock), y cortar transacciones para recuperar el sistema en caso de fallos masivos.

Tipos de sistemas de procesamiento de transacciones

Diferencias con el procesamiento por lotes
El procesamiento por lotes no es un procesamiento de transacciones. El procesamiento por lotes implica procesar varias transacciones al mismo tiempo, y no se dispone inmediatamente de los resultados del resto de transacciones cuando comienza cada una de ellas.

Caractersticas de los sistemas de procesamiento de transacciones

Respuesta rpida
En este tipo de sistemas resulta crtico que exista un rendimiento elevado con tiempos de respuesta cortos. Un negocio no puede permitirse tener clientes esperando por una respuesta del SPT; el tiempo total transcurrido desde que se inicia la transaccin hasta

que se produce la salida correspondiente debe ser del orden de unos pocos segundos o menos.

Fiabilidad
Muchas organizaciones basan su fiabilidad en los SPT; un fallo en un SPT afectar negativamente a las operaciones o incluso parar totalmente el negocio. Para que un SPT sea efectivo, su tasa de fallos debe ser muy baja. En caso de fallo de un SPT, debe existir algn mecanismo que permita una recuperacin rpida y precisa del sistema. Esto convierte en esencial la existencia procedimientos de copia de seguridad y de recuperacin ante fallos correctamente diseados.

Inflexibilidad
Un SPT requiere que todas las transacciones sean procesadas exactamente de la misma forma, independientemente del usuario, el cliente o la hora del da. Si los SPT fuesen flexibles, habra entonces demasiadas posibilidades de ejecutar operaciones no estndar. Por ejemplo, una aerolnea comercial necesita aceptar de forma consistente reservas de vuelos realizadas por un gran nmero de agencias de viaje distintas; aceptar distintos datos de transaccin de cada agencia de viajes supondra un problema.

Procesamiento controlado
El procesamiento en un SPT debe apoyar las operaciones de la organizacin. Por ejemplo, si una organizacin establece roles y responsabilidades para determinados empleados, el SPT debe entonces mantener y reforzar este requisito.

Propiedades ACID: Una primera definicin

Atomicidad
Los cambios de estado provocados por una transaccin son atmicos: o bien ocurren todos o bien no ocurre ninguno. Estos cambios incluyen tanto modificaciones de la base de datos, como envo de mensajes o acciones sobre los transductores.

Consistencia
Una transaccin es una transformacin de estado correcta. Las acciones consideradas en su conjunto no violan ninguna de las restricciones de integridad asociadas al estado. Esto implica que la transaccin debe ser un programa correcto.

Aislamiento
Incluso cuando varias transacciones se ejecuten de forma concurrente, para cada transaccin T debe parecer que el resto de transacciones se han ejecutado antes o despus de T, pero no antes y despus.

Durabilidad

Una vez que una transaccin ha finalizado con xito (compromiso), cambia hacia un estado estable a prueba de fallos.

ACID
En bases de datos se denomina ACID a un conjunto de caractersticas necesarias para que una serie de instrucciones puedan ser consideradas como una transaccin. As pues, si un sistema de gestin de bases de datos es ACID compliant quiere decir que el mismo cuenta con las funcionalidades necesarias para que sus transacciones tengan las caractersticas ACID. En concreto ACID es un acrnimo de Atomicity, Consistency, Isolation and Durability: Atomicidad, Consistencia, Aislamiento y Durabilidad en espaol.

Interrupcin

Atomicidad: es la propiedad que asegura que la operacin se ha realizado o no, y por lo tanto ante un fallo del sistema no puede quedar a medias. Consistencia: es la propiedad que asegura que slo se empieza aquello que se puede acabar. Por lo tanto se ejecutan aquellas operaciones que no van a romper la reglas y directrices de integridad de la base de datos. Aislamiento: es la propiedad que asegura que una operacin no puede afectar a otras. Esto asegura que la realizacin de dos transacciones sobre la misma informacin sean independientes y no generen ningn tipo de error. Durabilidad: es la propiedad que asegura que una vez realizada la operacin, sta persistir y no se podr deshacer aunque falle el sistema.

Cumpliendo estas 4 condiciones se considera ACID Compliant

Puesta en prctica
Poner las caractersticas ACID en ejecucin no es tan sencillo. El proceso de una transaccin requiere a menudo un nmero de cambios pequeos al ser realizado, incluyendo la puesta al da de los ndices que son utilizados en el sistema para acelerar bsquedas. Esta secuencia de operaciones puede fallar por un nmero de razones; por ejemplo, el sistema puede no tener ningn sitio disponible en sus accionamientos de disco, o puede haber sobrepasado su tiempo de CPU asignado. ACID sugiere que la base de datos pueda realizar todas estas operaciones inmediatamente. De hecho esto es difcil de conseguir. Hay dos clases de tcnicas populares: escribir a un registro antes de continuar y la paginacin de la sombra. En ambos casos, los bloqueos se deben implantar antes que la informacin sea actualizada, y dependiendo de la tcnica puesta en prctica, todos los datos se tienen que haber ledo. En escribir a un registro antes de continuar, la atomicidad es garantizada asegurndose que toda la informacin est escrita a un registro antes que se escriba a la base de datos. Eso permite que la base de datos vuelva a un estado anterior en caso de un desplome.

En sombrear, las actualizaciones se aplican a una copia de la base de datos, y se activa la nueva copia cuando la transaccin sea confiable. La copia refiere a partes sin cambios de la vieja versin de la base de datos, en vez de ser un duplicado entero. Esto significa que debe realizarse un bloqueo en cualquier momento antes de procesar datos en una base de datos, incluso en operaciones ledas. Mantener una gran cantidad de bloqueos da lugar a un aumento substancial indirecto de los procesos as como a una alteracin de la concurrencia de ellos. Si el usuario A est procesando una transaccin que ha ledo una fila de los datos que el usuario B desea modificar, por ejemplo, el usuario B debe esperar hasta que el otro usuario acabe. Una alternativa a la fijacin es mantener copias separadas de cualquier dato que se modifique. Esto permite a usuarios leer datos sin adquirir ningn bloqueo. Yendo de nuevo al ejemplo del usuario A y del usuario B, cuando la transaccin del usuario consigue los datos que el usuario B ha modificado, la base de datos puede recuperar la versin exacta de los datos que el usuario A comienza su transaccin. Esto asegura de que el usuario A consiga una vista constante de la base de datos aunque otros usuarios estn cambiando datos. Es difcil garantizar caractersticas en un ambiente de red. Las conexiones de red pudieron fallar, o dos usuarios pudieron utilizar la misma parte de la base de datos al mismo tiempo. El bifsico se aplica tpicamente en transacciones distribuidas para asegurarse de que cada participante en la transaccin conviene aceptar si se debe confiar en la transaccin no. El cuidado debe ser tomado al funcionar transacciones en paralelo. La fijacin bifsica se aplica tpicamente para garantizar el aislamiento completo. El concepto ACID se describe en ISO/IEC 10026-1: 1992 seccin 4.

Gestor transaccional
En computacin, un gestor transaccional es un componente que procesa informacin descomponindola de forma unitaria en operaciones indivisibles, llamadas transacciones. Cada transaccin debe finalizar de forma correcta o incorrecta como una unidad completa. No puede acabar en un estado intermedio.

Descripcin
Los gestores transaccionales se disean para mantener bases de datos en un estado conocido y consistente, asegurando que todas las operaciones que son interdependientes realizadas sobre la base de datos se han completado todas correctamente o se han cancelado todas. Por ejemplo, tmese un ejemplo tpico de una transaccin bancaria que requiere mover 500 de la cuenta de un cliente a otra. Esta transaccin es una operacin nica segn la visin del banco, pero requiere al menos dos operaciones desde la visin de la

computadora: restar 500 de la cuenta del cliente origen y sumarle 500 al cliente destino. Si la operacin de resta finaliza correctamente pero la operacin de suma no (o viceversa), el balance del banco al final del da no ser correcto. Por lo tanto, debe haber una forma de asegurar que ambas operaciones finalizan correctamente o incorrectamente y as evitar cualquier tipo de inconsistencia en la base de datos del banco. Un gestor transaccional proporciona esta caracteritica. Un gestor transaccional permite enlazar varias operaciones individuales automticamente como una sola e indivisible transaccin. El gestor garantiza que todas las operaciones finalizan sin errores o ninguna de ellas. Si algunas operaciones finalizaron correctamente pero otras no, el gestor inicia el proceso de rollback de todas las operaciones implicadas (incluso de aquellas que finalizaron correctamente), eliminando todo rastro de la transaccin y devolviendo la base de datos a un estado consistente como lo estaba antes de empezar a procesar la transaccin. Si todas las operaciones de la transaccin finalizaron correctamente, la transaccin realiza commit a los cambios realizados en la base de datos. Una vez se ha hecho commit, los datos de esa transaccin queda consolidados y la transaccin no puede hacer rollback de los cambios. Todas las transacciones se procesan en orden cronolgico. Si la transaccin n+1 modifica la misma rea que la transaccin n, la transaccin n+1 no puede empezar hasta que la transaccin n haya realizado commit de sus cambios. Ninguna transaccin puede realizar commit de sus modificaciones hasta que todas las transacciones anteriores que modifiquen la misma rea hayan realizado commit (o rollback) de sus cambios. No puede haber saltos de secuencia en la transacciones anteriores.

Metodologa
Los principios bsicos de cualquier sistema transaccional son los mismo. Sin embargo, la terminologa puede variar de un sistema a otro, los trminos utilizados aqu no tienen porque ser universales.

Rollback
Los gestores transacciones aseguran la integridad de las bases de datos registrando todos los estados intermedios de una base de datos mientras se modifica. En caso de que la transaccin falle, se usan esos registros para devolver la base de datos a un estado consistente. Por ejemplo, se copia informacin de la base de datos antes de que sea modificada por una transaccin, de tal manera que si parte de la transaccin acaba incorrectamente, se usan esas copias (llamadas before image) para restablecer la integridad de los datos (rollback).

Rollforward
Tambin es posible mantener un copia (llamada after image) de todas aquellas modificaciones realizadas sobre una base de datos. No es necesario para hacer rollback de las transacciones que finalizaron incorrectamente, pero s es til para actualizar la base de datos en un escenario de una recuperacin.

Si la base de datos falla estrepitosamente, la restauracin se debe iniciar desde la copia de seguridad ms reciente, aunque no reflejar aquellos cambios posteriores a la copia. Sin embargo, una vez se ha restablecido la copia de seguridad se aplica la copia after image que contendr todas las modificaciones entre la copia de seguridad y el fallo de la base de datos. Desgraciadamente, esta copia tambin contiene todas aquellas modificaciones que estaban en vuelo en el momento del fallo. Por ello, es necesario aplicar la copia before image que har rollback de las transacciones con un estado intermedio, devolviendo la base de datos a un estado seguro y consistente.

Bloqueos mutuos
En algunos casos, dos transacciones pueden en el transcurso de su ejecucin, competir por dos recursos al mismo tiempo de tal manera que impide seguir con su ejecucin. Un bloqueo mutuo (o interbloqueo, deadlock en ingls) ocurre, por ejemplo, cuando la transaccin A intenta acceder al rea X de la base de datos mientras la transaccin B intenta acceder al rea Y de la base de datos. Si, en algn punto intermedio, la transaccin A intenta acceder al rea Y mientras al mismo tiempo la transaccin B intenta acceder al rea X se genera un bloqueo mutuo que impide a ambas transacciones progresar. Los sistemas transacciones estn diseados para detectar este tipo de bloqueos cuando ocurren y actuar en concordancia. O bien ambas transacciones son canceladas y el sistema hace rollback de todos los cambios para luego volver a ejecutarlas automticamente en diferente orden de tal forma que no se vuelva a formar otro bloqueo mutuo, o bien cancelar y hacer rollback de una de ellas y volverla a lanzar despus de una pequea espera.