En ausencia de fallos, todas las transacciones se completan con éxito. Sin em- bargo, como se ha visto antes, una transacción puede que no siempre termine su ejecución con éxito. Una transacción de este tipo se denomina abortada. Si se pre- tende asegurar la propiedad de atomicidad, una transacción abortada, no debe tener efecto sobre el estado de la base de datos. Así, cualquier cambio que ha hecho la transacción abortada sobre la base de datos debe deshacerse. Una vez que se han deshecho los cambios efectuados por la transacción abortada, se dice que la tran- sacción está retrocedida. Parte, de la responsabilidad del esquema de recuperacio- nes es gestionar las transacciones abortadas (Silberschatz, Korth, Sudarshan 2006).
Una transacción que termina con éxito se dice que está comprometida. Una tran- sacción comprometida que ha hecho modificaciones transforma la base de datos lle- vándola a un nuevo estado consistente, que permanece incluso si hay un fallo en el sistema.
Cuando una transacción se ha comprometido no se pueden deshacer sus efectos abortándola. La única forma de deshacer los cambios de una transacción comprome- tida es ejecutando una transacción compensadora. Por ejemplo, si una transacción añade $ 20 a una cuenta, la transacción compensadora debería restar $ 20 de la cuenta. Sin embargo, no siempre se puede crear dicha transacción compensadora. Por tanto, se deja al usuario la responsabilidad de crear y ejecutar transacciones compensadoras.
Es necesario precisar qué se entiende por terminación con éxito de una transac- ción. Se establece, por tanto, un simple modelo abstracto de transacción. Una tran- sacción debe estar en uno de los estados siguientes:
Activa. El estado inicial; la transacción permanece en este estado durante su ejecu- ció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 a su estado anterior al comienzo de la transacción.
Comprometida. Tras completarse con éxito.
El diagrama de estados correspondiente a una transacción, se muestra en la figu- ra 5.1, se dice que una transacción se ha comprometido solo si ha llegado al estado de comprometida. Análogamente se dice que una transacción ha abortado sólo si ha llegado al estado de abortada. Una transacción se dice que ha terminado si se ha comprometido o bien se ha abortado.
Una transacción comienza en el estado activa. Cuando acaba su última instruc- ción pasa al estado de parcialmente comprometida. En este punto la transacción ha terminado su ejecución, sin embargo, es posible que aún tenga que ser abortada, puesto que los datos actuales pueden estar todavía en la memoria principal y puede producirse un fallo en el hardware antes de que se complete con éxito.
El sistema de base de datos escribe en disco la información suficiente para que, incluso al producirse un fallo, puedan reproducirse los cambios hechos por la tran- sacción al reiniciar el sistema tras el fallo. Cuando se termina de escribir esta infor- mación, la transacción pasa al estado de comprometida (Álvarez 2006).
Como se ha mencionado antes, se asume que los fallos no provocan pérdidas de datos en disco. Las técnicas para tratar las pérdidas de datos en disco.
Figura 5.1. Diagrama de transición de estado de una transacción.
Una transacción llega al estado fallida después de que el sistema determine que dicha transacción no puede continuar su ejecución normal, por ejemplo, a causa de errores de hardware o lógicos. Una transacción de este tipo se debe retroceder. Después pasa al estado abortado. En este punto, el sistema tiene dos opciones: • Reiniciar la transacción, sin embargo, sólo si la transacción se ha abortado a cau-
sa de algún error hardware o software que no lo ha provocado la lógica interna de la transacción. Una transacción reiniciada se considera una nueva transacción. • Cancelar la transacción. Normalmente se hace esto si hay algún error interno ló- gico que sólo se puede corregir escribiendo de nuevo el programa de aplicación, o debido a una entrada incorrecta o a que no se han encontrado los datos desea- dos en la base de datos.
Hay que tener cuidado cuando se trabaja con escrituras externas observables, como en un terminal o en una impresora. Cuando una escritura así tiene lugar, no puede borrarse puesto que puede haber sido vista fuera del sistema de base de da- tos. Muchos sistemas permiten que tales escrituras tengan lugar sólo después de que la transacción llegue al estado de comprometida. Una manera de implementar dicho esquema es hacer que el sistema de base de datos almacene temporalmente cualquier valor asociado con estas escrituras externas en memoria no volátil, y reali- za las escrituras actuales sólo si la transacción llega al estado de comprometida. Si el sistema falla después de que la transacción llegue al estado comprometida, sin embargo, antes de que finalicen las escrituras externas, el sistema de base de datos puede llevar a cabo dichas escrituras externas (utilizando los datos de la memoria no volátil) cuando el sistema se reinicie.
La gestión de las escrituras externas puede ser más complicada en ciertas situa- ciones. Por ejemplo, supóngase que la acción externa es dispensar dinero en un ca- jero automático y el sistema falla justo antes de que se dispense el dinero (se asume que el dinero se dispensa atómicamente). No tiene sentido dispensar el dinero cuan- do se reinicie el sistema, ya que el usuario probablemente no esté en el cajero. En tal caso es necesaria una transacción compensadora, como devolver el dinero a la cuenta del usuario.
Para algunas aplicaciones puede ser deseable permitir a las transacciones acti- vas que muestren datos a los usuarios, particularmente para transacciones de larga duración que se ejecutan durante minutos u horas. Pero, no se puede permitir dicha salida de datos observables a no ser que se quiera arriesgar la atomicidad de la tran- sacción. Muchos sistemas de bases de datos actuales aseguran la atomicidad y, por tanto, prohíben esta forma de interacción con el usuario.