LA ADMINISTRACIÓN DE LAS TRANSACCIONES DISTRIBUIDAS
“Una transacción es una secuencia de una o más operaciones agrupadas como una unidad”
El inicio y el final de la transacción definen los puntos de consistencia de la base de datos distribuida. Si una acción de la transacción no se puede ejecutar, entonces ninguna acción dentro de la secuencia que conforma la transacción tendrá efecto.
Las operaciones dentro de una transacción se almacenan temporalmente, no a nivel de disco. Es hasta que termina la transacción que se tienen efecto de manera permanente o no.
TRANSACCIONES
Provienen de los sistemas de Gestión de BD. En el contexto de las bases de datos distribuidas:
“Una transacción es la ejecución consistente y confiable de un conjunto de operaciones agrupadas como una unidad que acceden a una base de datos compartida”
En algunas situaciones, el cliente necesitan que una secuencia de operaciones a la base de datos distribuida se ejecuten de manera atómica:
libres de interferencia por operaciones de otros clientes.
Todas las operaciones se deben completar con éxito o no tener ningún efecto si el servidor falla
PROPIEDADES DE LAS TRANSACCIONES
Atomicidad. Se refiere al hecho de que una transacción se trata como una unidad de operación. Por lo tanto, o todas las acciones de la transacción se realizan o ninguna de ellas se lleva a cabo.
La atomicidad requiere que si una transacción se interrumpe por una falla, sus resultados parciales deben ser deshechos. La actividad referente a preservar la atomicidad de transacciones en presencia de abortos debido a errores de entrada, sobrecarga del sistema o interbloqueos se le llama recuperación de transacciones. La actividad de asegurar la atomicidad en presencia de caídas del sistema se le llama recuperación de caídas.
Consistencia. La consistencia de una transacción es simplemente su correctitud. En otras palabras, una transacción es un programa correcto que lleva la base de datos de un estado consistente a otro con la misma característica. Debido a esto, las transacciones no violan las restricciones de integridad de una base de datos.
3.Aislamiento. Una transacción en ejecución no puede revelar sus resultados a otras transacciones concurrentes antes de su commit. Más aún, si varias transacciones se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado de manera secuencial (seriabilidad).
4.Durabilidad. Es la propiedad de las transacciones que asegura que una vez que una transacción hace su commit, sus resultados son permanentes y no pueden ser borrados de la base de datos. Por lo tanto, los DBMS aseguran que los resultados de una transacción sobrevivirán a fallas del sistema. Esta propiedad motiva el aspecto de recuperación de bases de datos, el cual trata sobre como recuperar la base de datos a un estado consistente en donde todas las acciones que han hecho un commit queden reflejadas.
CONDICIONES DE TERMINACIÓN
Una transacción siempre termina, aun cuando exista un fallo.
Si una transacción termina de manera exitosa se dice que la transacción ha sido consumada: commit .
El resultado de una transacción consumada es almacenado en la base de datos de manera permanente y no se puede deshacer.
Si la transacción se detiene sin terminar su tarea, se dice que la transacción aborta.
Cuando la transacción es abortada, su ejecución se detiene y todas las acciones ejecutadas hasta el momento se deshacen (undone), regresando la base de datos al estado antes de su ejecución.
A esta operación también se le conoce como rollback.
TIPOS DE TRANSACCIONES
1.Áreas de aplicación. En primer lugar, las transacciones se pueden ejecutar en aplicaciones no distribuidas. Las transacciones que operan en datos distribuidos se les conoce como transacciones distribuidas. Por otro lado, dado que los resultados de una transacción que realiza un commit son durables, la única forma de deshacer los efectos de una transacción con commit es mediante otra transacción. A este tipo de transacciones se les conoce como transacciones compensatorias. Finalmente, en ambientes heterogéneos se presentan transacciones heterogéneas sobre los datos.
2.Tiempo de duración. Tomando en cuenta el tiempo que transcurre desde que se inicia una transacción hasta que se realiza un commit o se aborta, las transacciones pueden ser de tipo batch o en línea. Estas se pueden diferencias también como transacciones de corta y larga vida. Las transacciones en línea se caracterizan por tiempos de respuesta muy cortos y por accesar un porción relativamente pequeña de la base de datos. Por otro lado, las transacciones de tipo batch toman tiempos relativamente largos y accesan grandes porciones de la base de datos.
3.Estructura. Considerando la estructura que puede tener una transacción se examinan dos aspectos: si una transacción puede contener a su vez subtransacciones o el orden de las acciones de lectura y escritura dentro de una transacción.
TRANSACCIONES CENTRALIZADAS
Los datos tienen operaciones de lectura y escritura.
Las BBDD centralizadas tienen los datos en un solo nodo y puede haber acceso concurrente a los datos.
Una transacción se ha completado correctamente si anota un «COMMIT», o incorrectamente si ha declarado un «ABORT» explícitamente o bien implícitamente si el sistema ha crasheado de algún modo y no se ha apuntado ni COMMIT ni ABORT.
Comentarios
Publicar un comentario