UNIVERSIDAD PRIVADA SAN JUAN BAUTISTA ESCUELA PROFESIONAL DE INGENIERIA DE COMPUTACION Y SISTEMAS TRANSACCIONES Integrantes: Cancho Ramirez Kiara Angulo Rejas Grecia Monroy Lozano Max Olaya Huanaco Raul Miguelito Godoy Cartagena jose luis

CONCEPTO DE TRANSACCIÓN Una transacción es una unidad de la ejecución de un programa que accede y posiblemente actualiza varios elementos de datos. Una transacción se inicia por la ejecución de un programa de usuario escrito en un lenguaje de manipulación de datos de alto nivel o en un lenguaje de programación (por ejemplo SQL, C++ o Java). Atomicidad. O bien todas las operaciones de la transacción se realizan adecuadamente en la base de datos o ninguna de ellas. Consistencia La ejecución aislada de la transacción (es decir, sin otra transacción que se ejecute concurrentemente) conserva la consistencia de la base de datos Durabilidad. Tras la finalización con éxito de una transacción, los cambios realizados en la base de datos permanecen, incluso si hay fallos en el sistema.

ESTADOS DE UNA TRANSACCIÓN Se establece por tanto un simple modelo abstracto de transacción. Una transacción debe estar en uno de los estados siguientes: Activa, el estado inicial; la transacción permanece en este estado durante su ejecución. Parcialmente comprometida, después de ejecutarse la última instrucción. Fallida, tras descubrir que no puede continuar la ejecución normal. Abortada, después del retroceso de la transacción y de haber restablecido la base de datos la base de datos a su estado anterior al comienzo de la transacción. Comprometida, tras completarse con éxito.

IMPLEMENTACIÓN DE LA ATOMICIDAD Y LA DURABILIDAD El componente de gestión de recuperaciones de un sistema de base de datos implementa el soporte para la atomicidad y durabilidad. En primer lugar consideramos un esquema simple pero extremadamente ineficiente, denominado copia en la sombra. Este esquema, que se basa en hacer copias de la base de datos, denominadas copias sombra, asume que sólo una transacción está activa en cada momento. El esquema asume que la base de datos es simplemente un archivo en disco. En disco se mantiene un puntero llamado puntero_bd que apunta a la copia actual de la base de datos. En el esquema de copia en la sombra, una transacción que quiera actualizar una base de datos crea primero una copia completa de dicha base de datos. Todos los cambios se hacen en la nueva copia de la base de datos dejando la copia original, la copia en la sombra, inalterada. Si en cualquier punto hay que abortar la transacción, la copia nueva simplemente se borra. La copia antigua de la base de datos no se ve afectada.

EJECUCIONES CONCURRENTES Los sistemas de procesamiento de transacciones permiten normalmente la ejecución de varias transacciones concurrentemente. Sin embargo, existen dos buenas razones para permitir la concurrencia: Productividad y utilización de recursos mejoradas. Una transacción consiste en varios pasos. Algunos implican operaciones de E/S; otros implican operaciones de CPU. La CPU y los discos pueden trabajar en paralelo en una computadora. Por tanto, las operaciones de E/S se pueden realizar en paralelo con el procesamiento de la CPU. Tiempo de espera reducido. Debe haber una mezcla de transacciones que se ejecutan en el sistema, algunas cortas y otras largas. Si las transacciones se ejecutan secuencialmente, la transacción corta debe esperar a que la transacción larga anterior se complete, lo cual puede llevar a un retardo impredecible en la ejecución de la transacción

SECUENCIALIDAD El sistema de base de datos debe controlar la ejecución concurrente de las transacciones para asegurar que el estado de la base sigue siendo consistente. Antes de examinar cómo debe realizar esta tarea el sistema de base de datos hay que entender primero las planificaciones que aseguran la consistencia y las que no. Puesto que las transacciones son programas, es difícil calcular cuáles son las operaciones exactas que realiza una transacción y cómo interaccionan las operaciones de varias transacciones. Por este motivo no se van a interpretar los tipos de operaciones que puede realizar una transacción sobre un elemento de datos. En lugar de esto se consideran sólo dos operaciones: leer y escribir.

SECUENCIALIDAD EN CUANTO A CONFLICTOS Puesto que sólo se tienen en cuenta las instrucciones leer y escribir se deben considerar cuatro casos: 1. Ii = leer(Q), Ij = leer(Q). El orden de Ii e Ij no importa, puesto que Ti y Tj leen el mismo valor de Q, independientemente del orden. 2. Ii = leer(Q), Ij = escribir(Q). Si Ii está antes que Ij, entonces Ti no lee el valor de Q que escribe la instrucción Ij de Tj. Si Ij está antes que Ii, entonces Ti lee el valor de Q escrito por Tj. Por tanto, orden de Ii e Ij es importante. 3. Ii = escribir(Q), Ij = leer(Q). El orden de Ii e Ij es importante por razones similares a las del caso anterior. 4. Ii = escribir(Q), Ij = escribir(Q). Puesto que ambas instrucciones son operaciones escribir el orden de dichas instrucciones no afecta ni a Ti ni a Tj. Sin embargo, el valor que obtendrá la siguiente instrucción leer(Q) de P sí se ve afectado, ya que únicamente se conserva en la base de datos la última de las dos instrucciones escribir

SECUENCIALIDAD EN CUANTO A VISTAS En este apartado se va a considerar una forma de equivalencia que es menos rigurosa que la equivalencia en cuanto a conflictos pero que, al igual que ésta, se basa únicamente en las operaciones leer y escribir de las transacciones. Considérense dos planificaciones, P y P0, en las cuales participa el mismo conjunto de transacciones. RECUPERABILIDAD Se han estudiado las planificaciones que son aceptables desde el punto de vista de la consistencia de la base de datos asumiendo implícitamente que no había fallos en las transacciones. Ahora se va a estudiar el efecto de los fallos en una transacción durante una ejecución concurrente.. Si la transacción Ti falla, por la razón que sea, es necesario deshacer el efecto de dicha transacción para asegurar la propiedad de atomicidad de la misma.

PLANIFICACION SIN CASCADA Este fenómeno en el cual un fallo en una única transacción provoca una serie de retrocesos de transacciones se denomina retroceso en cascada. No es deseable el retroceso en cascada, ya que provoca un aumento significativo del trabajo necesario para deshacer cálculos. Es deseable restringir las planificaciones a aquéllas en las que no puedan ocurrir retrocesos en cascada. Tales planificaciones se denominan planificaciones sin cascada.

IMPLEMENTACIÓN DEL AISLAMIENTO Existen varios esquemas de control de concurrencia que se pueden utilizar para asegurar que, incluso si se ejecutan concurrentemente muchas transacciones, sólo se generen planificaciones aceptables sin tener en cuenta la forma en que el sistema operativo comparte en el tiempo los recursos (tales como el tiempo de CPU) entre las transacciones.