NDICE

INTRODUCCIN

------------------------------------------------------------1

TRANSACCIONES---------------------------------------------------------------3
APLICACIONES DE TRANSACCIONES-----------------------------------------3 DEFINICIN DE TRANSACCIONES-----------------------------------------------3 PROPIEDADES DE LAS TRANSACCIONES-----------------------------------4 INSTRUCCIONES PARA EL USO DE TRANSACCIONES------------------5 TCNICAS DE IMPLANTACIN DE TRANSACCIONES--------------------5 ESTRUCTURA DE TRANSACCIONES--------------------------------------------6 PROCESAMIENTO DE TRANSACCIONES--------------------------------------7 CONDICIONES DE TERMINACIN DE TRANSACCIONES----------------9 TRANSACCIONES EN LOS SISTEMAS DE ARCHIVOS DISTRIBUIDOS-10

CONTROL DE CONCURRENCIA-------------------------------------------10
ALGORITMOS DE CERRADURAS O BASADOS EN CANDADOS-----11 CONTROL OPTIMISTA DE LA CONCURRENCIA---------------------------13 ALGORIMOS BASADOS EN MARCAS DE TIEMPO-----------------------14 CONTROL DE CONCURRENCIA EN SISTEMAS DE ARCHIVOS-----14 DISTRIBUIDOS

INTRODUCCION
La gran cantidad de avances e innovaciones tecnolgicas que se produjeron en los ltimos aos tuvieron como resultado un cambio en la forma de observar a los sistemas de informacin, en general a las aplicaciones computacionales. Existen avances tecnolgicos que se realizan de forma constante en dispositivos de almacenamiento, circuitos, programas y metodologas. Dichos avances van de la mano junto con la demanda de los usuarios y programas para la explotacin de dichos dispositivos mejorados. Un rea en la cual las soluciones estn ocupando tecnologa con nuevas arquitecturas, es en la de los Sistemas distribuidos de informacin. Estos sistemas se refieren al manejo de datos almacenados en muchos Sitios ligados a travs de una red de comunicaciones. Un caso particular de estos sistemas distribuidos es lo que se conoce como base de datos distribuidas. En los sistemas de base de datos distribuidas se persigue la integracin de sistemas de base de datos diversos, no necesariamente homogneos para dar a los usuarios una visin global de la informacin disponible. Este proceso de integracin no implica la centralizacin de la informacin, mas bien, con la ayuda de la tecnologa de redes de computadoras la informacin se mantiene distribuida y los sistemas de bases de datos distribuidos permiten el acceso a ella como si estuviera localizada en un solo lugar. La distribucin de la informacin permite tener accesos rpidos a la misma, tener copias de la informacin para accesos ms rpidos y para tener respaldo en caso de fallas. Un sistema de base de datos distribuida es el resultado de la integracin de una base de datos distribuida con un sistema para su manejo. Existen diversos factores relacionados a la construccin de base de datos distribuidas que no se presentan en base de datos centralizadas los ms importantes son: Diseo de base de datos distribuida: Se debe considerar la forma de distribuir la informacin entre diferentes sitios, primero, como fragmentar la informacin, segundo, como asignar cada fragmento entre los diversos sitios de la red Se debe considerar tambin si la informacin esta replicada es decir, si existen copias mltiples del mismo dato y, en ese caso, como mantener la consistencia de la informacin. Procesamiento de consultas: En base de datos distribuidas el procesamiento de consultas adquiere mayor relevancia que en base de datos centralizadas. El objetivo es convertir transacciones de usuario en instrucciones para manipulacin de datos. Control de concurrencia: Es la actividad de coordinar accesos concurrentes a la base de datos, permite a los usuarios acceder a la base de datos de una forma multiprogramada mientras se mantiene la imagen de que cada usuario esta utilizndola solo en sistema dedicado. Asegura que transacciones mltiples sometidas por usuarios diferentes no interfieran unas con otras de forma que se produzcan resultados incorrectos. El control de concurrencia en base de datos distribuidas es ms compleja que en sistemas centralizados. Un aspecto interesante del control de concurrencia es el manejo de nterbloqueos, el sistema no debe permitir que dos o ms transacciones se bloqueen entre ellas.

Confiabilidad :

En cualquier sistema de base de datos, centralizado o distribuido, se debe ofrecer garantas de que la informacion es confiable. As cada consulta o actualizacin de la informacion se realiza mediante transacciones, las cuales tienen un inicio y un fin. En sistemas distribuidos, el manejo de atomicidad y durabilidad de las transacciones es aun ms complejo, ya que una sola transaccin puede involucrar dos o ms sitios de la red. Responsabilidades del gestor de la base de datos Manejo de transacciones en forma atmica: Puede ser muy frecuente que los datos sean totalmente incorrectos al ocurrir un fallo en una transaccin como un corto en la energa elctrica por ejemplo, por lo que una transaccin debe ocurrir por completo o no ocurrir en lo absoluto a esto se refiere la atomicidad.

Control de concurrencia o de los accesos simultneos a la base de datos: De no ser considerada esta responsabilidad se pueden dar el caso que una serie de actualizaciones a los mismos datos pero en tiempos minimamente diferentes, hagan que se pierdan todas las actualizaciones menos la ltima. Conservar la Seguridad de los datos (borrados accidentales, fallos diversos, catstrofes, etc.) mediante tcnicas de respaldo y recuperacin. Si no se considera esto podra ocurrir una caos en el sistema. Personalizacin (accesos no autorizados, intrusos, curiosos, etc.). Un ejemplo de lo que pasara de no tomarlo en cuenta sera que cualquier usuario podra tener acceso a toda la informacin existente en nuestra base de datos Integridad (reglas): De no tomarse en cuenta podran aceptarse datos invlidos, sin sentido.. Definir, construir y manipular bases de datos.
Tambin cabe mencionar como trabajan los sistemas de archivos distribuidos, sus caractersticas y propiedades, donde tambin se usa el modelo transaccional. Un sistema de archivos puede caracterizarse por las siguientes propiedades: <Estructura de los archivos <Atributos de los archivos <operaciones posibles sobre los archivos <Control de acceso y seguridad <Control de consistencia del propio sistema

Diferentes sistemas de archivos tienen modelos diferentes pero se usan ampliamente tres modelos. En el primero, un archivo es un bloque de datos sin ninguna estructura conocida para el servidor de archivos, dado que el servidor de archivos no conoce la estructura interna de sus archivos no puede ejecutar ninguna operacin sobre las partes de esos archivos. El segundo modelo nos presenta un modelo plano, que consiste en una secuencia ordenada de registros y en el cual los registros no necesitan ser todos del mismo tamao y tipo. El modelo mas general de archivos es el jerrquico, que toma la forma de un rbol. Cada nodo del rbol puede tener una etiqueta, un registro de datos, ambas cosas o ninguna. Todos los archivos tienen atributos que los describen, como mnimo cada archivo debe tener un nombre u otro identificador y un tamao indicando cuanto almacenamiento ocupa actualmente. Algunos atributos son creados con el archivo y permanecen inalterados, otros (por ejemplo, la fecha de la ltima modificacin) son mantenidos automticamente por el sistema. Una vez establecidas las caractersticas de los objetos de trabajo, cada sistema brinda algn mecanismo para manipular los mismos, es decir, un conjunto de operaciones que pueden

efectuarse sobre el sistema de archivos. Las operaciones de archivos pueden aplicarse a un archivo como un todo o a los registros individuales que lo componen. Algunos sistemas de archivos soportan operaciones de directorio. Los usuarios pueden crear y borrar directorios, mover archivos de un directorio a otro etc. Todos los sistemas de archivos deben enfrentarse de alguna manera con el control de acceso y la proteccin de sus datos. La forma mas simple y menos confiable es asumir que todas las maquinas clientes son honestas y solo llevan a cabo los pedidos que correspondan. En una red pblica la direccin del llamador provista por el concesionario del servicio durante el establecimiento de la conexin puede ser suficiente para autenticar al llamador como un equipo confiable. Por otro lado, las computadoras personales sobre una LAN son elementos ms peligrosos, por lo que se necesitan mejores mtodos para estos casos. Uno de esos mtodos es verificar el emisor de cada pedido, ya sea incluyendo un password en cada pedido o usando algn mtodo de autenticacin digital. Un mtodo mas elaborado es tener una o ms password por archivo (una para lectura y otra para escritura, por ejemplo) . El ltimo detalle en analizar de los sistemas de archivos es el de la consistencia del mismo. El problema se plantea a partir que la manipulacin de datos, tanto de usuario como del sistema, se lleva a cabo bsicamente en memoria mientras que el disco sirve como almacenamiento estable y como soporte intermedio para operaciones con grandes volmenes de datos. As puede ocurrir que, ante una eventualidad, no puedan reflejarse adecuadamente en el disco los cambios llevados a cabo en memoria dando lugar, por ejemplo, a bloques que pretenden ser utilizados por mas de un archivo, a bloques que no estn marcados como ocupados pero que tampoco forman parte de un archivo, etc.-

TRANSACCIONES
Los sistemas distribuidos son muy confiables debido a la posibilidad de brindar redundancia y autonoma de recursos en diferentes nodos, esto posibilita detectar y localizar fallas, sin embargo tenemos varios aspectos que representan problemas para la integridad de los recursos y que a su vez motivan el uso de transacciones <Dificultad para mantener consistencia en los datos <Una misma va de comunicacin no siempre puede ser utilizada para suministrar interaccin entre dos procesos <Requerimientos de procesamientos en paralelo <Manejo interactivo de uno o mas usuarios APLICACIONES DE TRANSACIONES <Base de datos <Base de datos distribuidas <Sistema de archivos distribuidos <Desarrollo de aplicaciones tolerantes a fallos DEFINICIN DE TRANSACIONES Las transacciones fueron originalmente desarrolladas para ser utilizadas dentro de los sistemas de base de datos, donde se usaba para ayudar en el mantenimiento de los datos de las aplicaciones y que dependan de la consistencia de la informacion almacenada.

Las transacciones son mecanismos que ayudan a simplificar la construccin de sistemas confiables mediante procesos que proporcionan soporte uniforme para invocar y sincronizar operaciones como: <Operaciones de comparacin de datos <Aseguramiento de la seriabilidad de las transacciones con otras <Atomicidad en su comportamiento <Recuperacin de fallas La palabra transaccin describe una secuencia de operaciones con uno o ms recursos que transforman su estado actual en un nuevo estado de consistencia. Es un conjunto de operaciones sobre datos que son tratadas como una unidad. Una transaccin puede terminar, haciendo sus cambios persistentes, o abortar voluntaria o involuntariamente. Dentro del rea de los sistemas computacionales el concepto de transacciones fue inicialmente utilizado para definir la consistencia entre mltiples usuarios en una base de datos. Una transaccin es una coleccin de operaciones que hacen transformaciones consistentes de los estados de un sistema conservando la consistencia del sistema. Una base de datos esta en estado consistente si cumple todas las restricciones de integridad definidas sobre ella. Los cambios de estado se dan debido a actualizacin, insercin y eliminacin de la informacion. Se quiere asegurar que la base de datos no entre en un estado de inconsistencia, pero durante la ejecucin de una transaccin, la base de datos puede estar temporalmente en un estado inconsistente. Lo importante aqu es asegurar que la base de datos vuelva aun estado consistente al concluir la ejecucin de una transaccin (Figura A)

Figura A . Un modelo de transaccin. Lo que se persigue con el uso de transacciones es por un lado contar con una transparencia adecuada de las acciones concurrentes a una base de datos y por el otro tener una transparencia adecuada en el manejo de las fallas que se pueden presentar en una base de datos. Comentario sobre el modelo Una transaccin es una accin atmica, siendo una unidad de control de concurrencia y de recuperacin. Las transacciones se mantienen consistentes solo si se efecta a partir de un estado consistente. Las transacciones simplifican el modelo computacional dado que proveen: < Transparencia de concurrencia < Transparencia de fallos PROPIEDEADES DE LAS TRANSACCIONES

 Atomicidad: Una transaccin es tratada como una unidad de operacin. Por lo tanto todas las acciones de la transaccin se llevan a cabo o ninguna de ellas se realiza .La atomicidad requiere que si una transaccin se interrumpe por una falla, sus resultados parciales deben ser deshechos. Se efectan todas las transacciones, pero en caso de fallas no se realiza ninguna. Una transaccin debe concluir comprometida o abortada. En el caso del compromiso se instalan todas las actualizaciones y en el aborto se descartan todas las actualizaciones. Consistencia : Una transaccin es un programa correcto que lleva la base de datos de un estado consistente a otro con la misma caracterstica. Gracias a esto, las transacciones no violan las reglas de integridad de una base de datos.
Aislamiento : Durante la ejecucin de una transaccin, esta no debe revelar sus resultados a otras transacciones concurrentes antes de su compromiso. Si varias transacciones se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado en forma secuencial (Seriabilidad). La seriabilidad consiste en asegurarse que los cambios siguen un orden adecuado. Durabilidad : Es la propiedad de las transacciones que asegura que una vez que una transaccin realiza su compromiso, sus resultados son permanentes y no pueden ser borrados de la base de datos, se asegura que los resultados de una transaccin sobrevivirn a fallas del sistema. Las transacciones brindan una ejecucin atmica y confiable en presencia de fallas, una ejecucin correcta en presencia de accesos de usuario mltiples y un manejo correcto de replicas (en el caso que se soporten).

INSTRUCCIONES PARA EL USO DE TRANSACIONES La programacin con uso de transacciones requiere de instrucciones especiales, las cuales deben ser proporcionadas por el sistema operativo, por el compilador del lenguaje o por el manejador de la base de datos, algunos son: BEGIN _TRANSACCIN: Los comandos siguientes forman una transaccin END _ TRANSACCIN: Termina la transaccin y se intenta un compromiso ABORT_ TRANSACCIN: Se elimina la transaccin, se recuperan los valores anteriores READ: Se leen datos de un archivo WRITE: Se escriben datos en un archivo Las operaciones entre BEGIN y END forman el cuerpo de la transaccin y deben ejecutarse todas o ninguna de ellas. La cantidad exacta de instrucciones disponibles para manejar transacciones depende del tipo de objetos y operaciones que deban ser procesadas. TCNICAS DE IMPLANTACIN DE TRANSACCIONES

> rea de trabajo privada > Bitcora de escritura anticipada > Protocolo de compromiso de dos fases (two-phase)

1. rea de trabajo privada:

Consiste en realizar copias de los bloques que sern utilizados dentro de una transaccin de manera que se trabaje con estas copias para realizar todas las modificaciones necesarias. Todo el espacio de trabajo con la informacion que ser utilizada es contenida dentro de estas copias denominado rea de trabajo privada. Los dems usuarios trabajaran con la copia original de los bloques pero no podrn obtener una segunda copia de los mismos. Al iniciarse la transaccin el proceso obtiene una copia privada de los datos.Lecturas y escrituras sobre la zona privada. Para optimizar solo se crean copias privadas de los datos modificados. Una segunda optimizacin para los datos que estn organizados en bloques apuntados desde un ndice, como los ficheros, es crear copias solo de los fragmentos modificados.

2. Bitcora de escritura anticipada:

Este mtodo consiste en realizar una copia con todas las transacciones que van siendo ejecutadas hacia un bloque o espacio (LOG) de trabajo que sea estable, esta lista se la conoce como lista de intenciones. Las transacciones sern actualizadas con la informacion una vez que se ha determinado el fin de la transaccin. Se modifican los datos pero antes se escribe en un log sobre memoria estable la descripcin de la operacin. En el log tambin se escriben registros para indicar el inicio y fin de la transaccin, cuando se aborta la transaccin se recorre el log para deshacer los cambios. Despus de una cada temporal, se debe recorrer el log. Si una transaccin no ha escrito su registro de fin se aborta, si lo ha escrito, se hacen los cambios pendientes. Para evitar recorrer todo el log despus de un fallo temporal de la maquina, se usan generalmente checkpoints.

3. Protocolo de compromiso de dos fases:

En un sistema distribuido una transaccin puede afectar a varios procesadores lo cual dificulta la atomicidad. La solucin ms tpica es el protocolo de compromiso de dos fases (C2F). En este protocolo existe un coordinador que normalmente es el proceso que inicio la transaccin. Fase 1: El coordinador escribe en el log almacenado en memoria estable el registro (preparar T). Manda un mensaje con ese contenido a los nodos implicados en la transaccin. Cada proceso implicado decide si esta listo para hacer el compromiso, escribe en su log la decisin (listo T o no listo T) y la manda en un mensaje al coordinador. Fase 2: Si el coordinador recibe alguna respuesta negativa u obtiene alguna falla de respuesta decide abortar la transaccin. En caso contrario decide realizar el compromiso. El coordinador escribe en el log la decisin y manda un mensaje a los procesos implicados. Cada proceso que recibe el mensaje escribe en su log la decisin del coordinador y realiza la accin correspondiente.

La terminacin de una transaccin se hace mediante la regla del compromiso global. El coordinador aborta una transaccin si y solo si al menos un proceso implicado decide abortar. El coordinador hace un compromiso de la transaccin si y solo si todos los participantes deciden realizar el compromiso. Comportamiento ante un fallo de un nodo: El nodo N se recupera despus de una cada transitoria y detecta que la transaccin T estaba a medias. Si el log contiene (compromiso T) se realiza la transaccin. Si contiene (abort T) se aborta la transaccin, si contiene (listo T) debe consultar al coordinador para determinar si se compromete o aborta la transaccin, si no hay mensajes en el log se aborta. Comportamiento ante fallos del coordinador: Cada nodo implicado N debe decidir sobre la transaccin T. Si el log contiene (compromiso T) se realiza la transaccin. Si contiene (abort T) se aborta, si no contiene (listoT) el coordinador no ha podido decidir el compromiso, por lo tanto, lo mas apropiado es abortar la transaccin. Si todos los nodos tienen (listo T) pero ninguno tiene (compromiso T) o (abort T) no se puede determinar la decisin del coordinador. Se debera esperar que se recuperase.

ESTRUCTURA DE LAS TRANSACCIONES La estructura de una transaccin usualmente viene dada segn el modelo de la transaccin, estas pueden ser planas (simples) o anidadas. Transacciones planas:

Consisten en una secuencia de operaciones primitivas encerradas entre las palabras clave BEGIN y END. Por ejemplo: BEGIN _TRANSACTION Reservacin .... END.

Transacciones Anidadas :

Consiste en tener transacciones que dependen de otras, estas transacciones estn incluidas dentro de otras de un nivel superior y se las conoce como subtransacciones. La transaccin de nivel superior puede producir hijos (subtransacciones) que hagan ms fcil la programacin del sistema y mejoras del desempeo. En las transacciones anidadas las operaciones de una transaccin pueden ser as mismo otras transacciones. Por ejemplo: BEGIN _TRANSACTION Reservacin .......... BEGIN _TRANSACTION Vuelo ........ END.( Vuelo ) ...... BEGIN _TRANSACTION Hotel ........ END

...... END. Una transaccin anidada dentro de otra conserva las mismas propiedades que las de su padre, esto implica, que puede contener as mismo transacciones dentro de ella. Existen restricciones obvias en una transaccin anidada: debe empezar despus que su padre y debe terminar antes que el. El compromiso de una subtransaccion es condicional al compromiso de su padre, si el padre de una o varias subtransacciones aborta, las subtransacciones hijas tambin sern abortadas. Las transacciones anidadas brindan un nivel mas alto de concurrencia entre transacciones. Ya que una transaccin consiste de varias transacciones es posible tener mayor concurrencia dentro de una sola transaccin. As tambin, es posible recuperarse de de fallas de forma independiente de cada subtransaccion. Esto limita el dao a una parte mas pequea de la transaccin, haciendo que el costo de la recuperacin sea el menor. Tambin se deben considerar el orden de las lecturas y escrituras. Si las acciones de lectura y escritura pueden ser mezcladas sin ninguna restriccin, entonces, a este tipo de transacciones se les conoce como Generales .Por el contrario, si se restringe o impone que un dato debe ser ledo antes de que pueda ser escrito entonces se tendrn transacciones Restringidas. Si las transacciones son restringidas a que todas las acciones de lectura se realicen antes de las acciones de escritura entonces se les conoce como de Dos Pasos. Finalmente existe un modelo de accin para transacciones restringidas en donde se aplica aun ms la restriccin de que cada par < read , write > tiene que ser ejecutado de manera atmica.

PROCESAMIENTO DE TRANSACCIONES Los siguientes son los aspectos ms importantes relacionados con el procesamiento de transacciones:

Modelo de estructura de transacciones Es importante considerar si las transacciones son planas o anidadas. Consistencia de la base de datos interna Los algoritmos de control de datos tienen que satisfacer las restricciones de integridad cuando una transaccin pretende hacer un compromiso. Protocolos de confiabilidad En transacciones distribuidas es necesario introducir medios de comunicacin entre los diferentes nodos de una red para garantizar la atomicidad de las transacciones. Algoritmos de control de concurrencia Deben sincronizar la ejecucin de transacciones concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas.
Protocolos de control de replicas Se refiere a como garantizar la consistencia mutua de datos replicados. El procesamiento de transacciones bsicamente consiste en una serie de modificaciones (transacciones) a un determinado recurso del sistema (por ejemplo una base de datos) y en donde se define un punto de inicio y un punto de terminacin que define un bloque entre el conjunto de operaciones que son realizadas.

Dentro de este proceso en bloque los dems usuarios no pueden modificar nada hasta que no se presente un estado estable de los datos, esto ocasiona inconsistencia temporal y conflictos. Para evitar lo anterior se implementan dos maneras diferentes: <Ejecucin de transacciones serializadas < Ejecucin de transacciones calendarizadas

1- Ejecutar transacciones serializadas: Es un sistema que permite el procesamiento de transacciones en forma secuencial o serializado dndole una secuencia a cada transaccin, este proceso reduce el rendimiento del sistema, pero tiene como ventaja que el proceso de sincronizacin es ms sencillo.
2- Ejecutar transacciones calendarizadas: Permite el proceso de transacciones asignndoles tiempos de procesamiento el cual permite incrementar el rendimiento del sistema ya que se ejecuta un mximo de procesos en forma concurrente y no a travs de una serie. La ventaja es que a un mismo tiempo de reloj se pueden hacer dos operaciones, aunque el proceso de sincronizacin es mas complicado.

Un aspecto muy importante en el manejo de transacciones es el de mantener y aplicar algoritmos de control sobre los datos o recursos; para ese control tambin se utilizan protocolos que proporcionen confiabilidad como lo siguientes: < Atomicidad < Protocolos de recuperacin total < Protocolos de compromiso global

El control de las transacciones tambin requiere de controlar la concurrencia del acceso y uso hacia el recurso que se esta manipulando, ese control de concurrencia tiene dos objetivos: < Como sincronizar la ejecucin concurrente de transacciones < Consistencia intra transaccin (Aislamiento) Para llevar a cabo el control de concurrencia dentro de un proceso de transacciones se manejan dos modos: < Ejecucin centralizada de transacciones (Figura B) < Ejecucin distribuida de transacciones (Figura C)

Figura B. Ejecucin centralizada de transacciones.

Figura C. Ejecucin distribuida de transacciones.

CONDICIONES DE TERMINACION DE UNA TRANSACCION Una transaccin siempre termina, aun en la presencia de fallas. Si una transaccin termina de manera exitosa se dice que la transaccin hace un compromiso. Si la transaccin se detiene sin terminar su tarea, se dice que la transaccin aborta . Cuando la transaccin es abortada, puede ser por distintas razones relacionadas con la naturaleza de la transaccin misma, o por conflicto con otras transacciones o por fallo de un proceso o computador, entonces su ejecucin es detenida y

todas las acciones ejecutadas hasta el momento son deshechas regresando a la base de datos al estado antes de su ejecucin. A esta operacin tambin se la conoce como rollback.

TRANSACCIONES EN LOS SISTEMAS DE ARCHIVOS DISTRIBUIDOS Como alternativa a tener clientes que instalen bloqueos individuales, algunos servidores de archivos soportan acciones atmicas, a menudo llamadas transacciones. Cuando esta disponible esta facilidad, un cliente puede indicarle al servidor que comience una transaccin, seguida por cualquier numero de aperturas y operaciones de archivos, y finalizar con un comando para terminar la transaccin. El servidor debe ser capaz de llevar a cabo todos los pedidos efectuados de forma atmica (indivisible) sin interferencia de otros pedidos de clientes. Si el cliente decide abortar la transaccin o finalizan sus temporizadores, todos los archivos son restaurados al estado anterior al comienzo de la transaccin. Una transaccin es cualquier operacin de E/S sobre un archivo que modifica el contenido de un archivo existente del mismo. Esto incluye el agregar datos, cambiar el tamao y sobrescribir datos existentes. En una implementacin, junto al archivo de datos existe el denominado transaction log file que mantiene la descripcin de las modificaciones hechas sobre el archivo de datos y el mantenimiento de este archivo se llama transaction tracking. La operacin denominada transaction rollback es aquella por la cual las alteraciones indicadas en el log se deshacen retornando los datos al estado previo (estado inicial), que se supone consistente.

Dentro de los objetivos de diseo de un sistema de transacciones se tienen: < Minimizar la sobrecarga de los sistemas de archivos , < Identificar automticamente las inconsistencias de datos. Una vez identificados debe producirse una operacin rollback sin la intervencin del usuario. Obviamente mientras se produce esta operacin, debe negarse el acceso a los archivos potencialmente corruptos. < maximizar la portabilidad. La clave esta en la posibilidad de volver al punto de partida y, si corresponde, rehacer las operaciones. Para ello debe disponerse de la siguiente informacion: < Identificacin completa y univoca del archivo de datos. < El modo y los permisos utilizados al abrir el archivo. < La ubicacin de los datos modificados. < Una copia de los datos originales. < La descripcin de la alteracin que tuvo lugar. < Los datos con que se llevo a cabo tal modificacin.

Esta informacion convenientemente organizada, forma el ncleo de los denominados registros de transacciones, la unidad de datos de datos de los archivos log

EL CONTROL DE CONCURRENCIA EN EL MODELO TRANSACCIONAL

Los bloqueos se pueden definir formalmente como sigue: "Un conjunto de procesos se bloquean si cada proceso del conjunto esta esperando un evento que solo otro proceso del conjunto puede provocar". Puesto que todos los procesos estn en espera, ninguno de ellos podr ocasionar nunca ninguno de los eventos que podran desbloquear a algunos de los otros miembros del conjunto y los dems procesos seguirn esperando indefinidamente El control de concurrencia trata sobre los problemas de aislamiento y consistencia del procesamiento de transacciones. El control de concurrencia distribuido en sistema de manejo de bases de datos distribuidas asegura que la consistencia de la base de datos se mantiene, en un ambiente distribuido multiusuario. Si las transacciones son internamente consistentes, la manera ms simple de lograr este objetivo es ejecutar cada transaccin sola, una despus de otra. Sin embargo esto puede afectar enormemente el desempeo de un sistema de manejo de bases de datos distribuidas dado que el nivel de concurrencia se reduce al mnimo. El nivel de concurrencia, el numero de transacciones activas, es probablemente el parmetro mas importante en sistemas distribuidos. Los mecanismos de control de concurrencia buscan encontrar un balance entre el mantenimiento de la consistencia de la base de datos y el mantenimiento de un alto nivel de concurrencia. El fallo en diseo de mecanismos apropiados de sincronizacin y en obligar su uso por cada proceso que utiliza recursos comunes, produce frecuentemente un comportamiento errneo del sistema y rupturas que son notablemente difcil de depurar. La concurrencia puede producir un incremento de la productividad cuando se implementan correctamente, pero puede tambin degradar la fiabilidad cuando la sincronizacin impropia entre procesos contamina el sistema con errores artificios de tiempo. Si no se lleva a cabo un adecuado control de concurrencia, se podran llegar a presentar dos anomalas. En primer lugar, se pueden perder actualizaciones provocando que los efectos de algunas transacciones no se reflejen en la base de datos. En segundo lugar, pueden presentarse recuperaciones de informacion inconsistentes. Los algoritmos para el control de concurrencia son tiles cuando se ejecutan varias transacciones al mismo tiempo Los principales algoritmos son: < Los de cerradura o basados en candados < El de control optimista de la concurrencia < El de las marcas de tiempo El conjunto de algoritmos pesimistas esta formado por algoritmos basados en candados, algoritmos basados en ordenamiento por estampas de tiempo y algoritmos hbridos. Los algoritmos optimistas se componen por los algoritmos basados en candados y algoritmos basados en estampas de tiempo. (Figura D)

Figura D. Clasificacin de los algoritmos de control de concurrencia.

ALGORITMOS DE CERRADURA O BASADOS EN CANDADOS En los algoritmos basados en candados, las transacciones indican sus intenciones solicitando candados al despachador (llamado el administrador de candados) Los candados son de lectura , tambin llamados compartidos, o de escritura , tambin llamados exclusivos. En sistemas basados en candados, el despachador es un administrador de candados . El administrador de transacciones le pasa al administrador de candados la operacin sobre la base de datos (lectura o escritura) e informacin asociada, como por ejemplo el elemento de datos que es accesado y el identificador de la transaccin que est enviando la operacin a la base de datos. El administrador de candados verifica si el elemento de datos que se quiere accesar ya ha sido bloqueado por un candado. Si el candado solicitado es incompatible con el candado con que el dato est bloqueado, entonces, la transaccin solicitante es retrasada. De otra forma, el candado se define sobre el dato en el modo deseado y la operacin a la base de datos es transferida al procesador de datos. El administrador de transacciones es informado luego sobre el resultado de la operacin. La terminacin de una transaccin libera todos los candados y se puede iniciar otra transaccin que estaba esperando el acceso al mismo dato. Se usan cerraduras o candados de lectura o escritura sobre los datos. Para asegurar la secuencialidad se usa un protocolo de dos fases, en la fase de crecimiento de la transaccin se establecen los cerrojos y en la fase de decrecimiento se liberan los cerrojos. Hay que tener en cuenta que se pueden producir nterbloqueos. En los sistemas distribuidos el nodo que mantiene un dato se encarga normalmente de gestionar los cerrojos sobre el mismo. Candados de dos fases : En los candados de dos fases una transaccin le pone un candado a un objeto antes de usarlo. Cuando un objeto es bloqueado con un candado por otra transaccin, la transaccin solicitante debe esperar. Cuando una transaccin libera un candado, ya no puede solicitar ms

candados. En la primera fase solicita y adquiere todos los candados sobre los elementos que va a utilizar y en la segunda fase libera los candados obtenidos uno por uno. Puede suceder que si una transaccin aborta despus de liberar un candado, otras transacciones que hayan accesado el mismo elemento de datos aborten tambin provocando lo que se conoce como abortos en cascada. Para evitar lo anterior, los despachadores para candados de dos fases implementan lo que se conoce como los candados estrictos de dos fases en los cuales se liberan todos los candados juntos cuando la transaccin termina (con compromiso o aborta). Candados de dos fases centralizados: En sistemas distribuidos puede que la administracin de los candados se dedique a un solo nodo del sistema, por lo tanto, se tiene un despachador central el cual recibe todas las solicitudes de candados del sistema. La comunicacin se presenta entre el administrador de transacciones del nodo en donde se origina la transaccin , el administrador de candados en el nodo central y los procesadores de datos de todos los nodos participantes. Los nodos participantes son todos aquellos en donde la operacin se va a llevar a cabo.

Figura E. Comunicacin en un administrador centralizado de candados de dos fases.

La crtica ms fuerte a los algoritmos centralizados es el "cuello de botella" que se forma alrededor del nodo central reduciendo los tiempos de respuesta de todo el sistema. Su disponibilidad es reducida a cero cuando se presentan fallas en el nodo central. Candados de dos fases distribuidos: En los candados de dos fases distribuidos se presentan despachadores en cada nodo del sistema. Cada despachador maneja las solicitudes de candados para los datos en ese nodo. Una transaccin puede leer cualquiera de las copias replicada del elemento x, obteniendo un candado de lectura en cualquiera de las copias de x. La escritura sobre x requiere que se obtengan candados para todas las copias de x. Los mensajes de solicitud de candados se envan a todos los administradores de candados que participan en el sistema. Las operaciones son pasadas a los procesadores de datos por los administradores de candados. Los procesadores de datos envan su mensaje de "fin de operacin" al administrador de transacciones coordinador

Figura F. Comunicacin en candados de dos fases distribuidos

CONTROL OPTIMISTA DE LA CONCURRENCIA Los algoritmos de control de concurrencia pesimistas asumen que los conflictos entre transacciones son muy frecuentes y no permiten el acceso a un dato si existe una transaccin conflictiva que accesa el mismo dato. As, la ejecucin de cualquier operacin de una transaccin sigue la secuencia de fases: validacin , lectura , cmputo y escritura (ver Figura G). Los algoritmos optimistas, por otra parte, retrasan la fase de validacin justo antes de la fase de escritura (ver Figura G). De esta manera, una operacin sometida a un despachador optimista nunca es retrasada. Las operaciones de lectura, cmputo y escritura de cada transaccin se procesan libremente sin actualizar la base de datos corriente. Cada transaccin inicialmente hace sus cambios en copias locales de los datos. La fase de validacin consiste en verificar si esas actualizaciones conservan la consistencia de la base de datos. Si la respuesta es positiva, los cambios se hacen globales (escritos en la base de datos corriente). De otra manera, la transaccin es abortada y tiene que reiniciar Lo que se hace es dejar ejecutar las transacciones y si al terminar se detecta que ha habido conflicto se aborta y se reinicia la transaccin. Cada transaccin tiene tres fases:. < Fase de lectura: Cuerpo de la transaccin donde se copian datos desde la base de datos, copias que pueden ser actualizadas pero sin copiar a la base de datos < Fase de validacin: Se comprueba que no existan conflictos < Fase de escritura: Si no existen conflictos se instalan lo cambios en la base de datos

Conflictos entre operaciones: Dos operaciones estn en conflicto entre si cuando, operan sobre los mismos datos, una de las operaciones es de escritura, o cada operacin pertenece a diferentes transacciones.

Figura G. Fases de la ejecucin de una transaccin a) pesimista, b) optimista

ALGORITMOS BASADOS EN MARCAS DE TIEMPO A diferencia de los algoritmos basados en candados, los algoritmos basados en marcas de tiempo no pretenden mantener la seriabilidad por la exclusin mutua. En su lugar eligen un orden de serializacion en primera instancia y ejecutan las transacciones de acuerdo a ese orden. En estos algoritmos cada transaccin lleva asociada una marca de tiempo. Cada dato lleva asociado dos marcas de tiempo: uno de lectura y otro de escritura, que reflejan la marca de tiempo de la transaccin que hizo la ultima operacin de ese tipo sobre el dato. Para leer la marca de tiempo de escritura del dato, debe ser menor que el de la transaccin, si no aborta. Para escribir las marcas de tiempo de escritura y lectura del dato, deben ser menores que el de la transaccin, sino se aborta. Esta tcnica esta libre de nterbloqueos pero puede darse que halla que repetir varias veces la transaccin. En los sistemas distribuidos se puede usar un mecanismo como, los relojes de Lamport para asignar marcas de tiempo.

CONTROL DE CONCURRENCIA EN SISTEMAS DE ARCHIVOS DISTRIBUIDOS Hasta aqu se a hablado sobre el modelo transaccional haciendo hincapi en lo referido a base de datos distribuidas. En adelante se desarrollara como se emplea el control de concurrencia en sistemas distribuidos de archivos Los sistemas de archivos que forman parte de una red de computadoras tienen mltiples clientes de los que encargarse. Si dos o mas clientes, accidentalmente o no, deciden acceder al mismo archivo al mismo tiempo pueden producirse conflictos. La solucin utilizada es permitir a los usuarios el uso de bloqueos sobre los archivos de trabajo. La idea es sencilla, mientras un usuario esta trabajando sobre una parte de los datos, otros no podrn hacerlo de manera que las distintas actualizaciones se efectuaran en forma sucesiva y ordenada sin interferencias. Se utilizan dos clases de bloqueos: Los bloqueos compartidos que por lo

general se usan para lectura , y los bloqueos exclusivos que normalmente se usan para escritura. La granularidad del bloqueo es otra consideracin importante. Es posible bloquear archivos enteros, pero tambin es posible bloquear archivos enteros o subrboles, cuanto menor sea la unidad lgica bloqueada mayor ser la concurrencia admisible. El concepto de bloqueo introduce varios problemas de contrapartida. Primero, si un cliente necesita acceder a varios archivos, como ocurre de forma comn cuando se efectan transferencias de dinero en aplicaciones bancarias, hay una posibilidad de abrazo mortal. Abrazos mortales: Principalmente, existen dos mtodos para manejar el problema de los abrazos mortales. Podemos usar algn protocolo para asegurar que el sistema nunca entrar en un estado de abrazo mortal. Alternativamente, podemos permitir que el sistema entre en un estado de abrazo mortal y despus recuperarnos. El recuperarse de un abrazo mortal puede ser muy difcil y muy caro. Por ello, primeramente consideraremos los mtodos para asegurar que no ocurran los abrazos mortales. Comnmente, existen dos mtodos. El de PREVENCIN de abrazos mortales y el de EVASIN de abrazos mortales. Un conjunto de procesos est en un abrazo mortal cuando todos los procesos en ese conjunto estn esperando un evento que slo puede ser causado por otro proceso en el conjunto. Los eventos a los cuales nos estamos refiriendo son concernientes con la asignacin y liberacin de recursos principalmente. Sin embargo, pueden llevar a la existencia de abrazos mortales. Para ejemplificar un estado de abrazo mortal, se considerara un sistema con tres unidades de disco. Supongamos que existen tres procesos, cada uno de ellos tiene asignada una de las unidades de disco. Si ahora cada proceso pide otra unidad de disco, los tres procesos se encuentran ahora en un estado de abrazo mortal. Cada uno esta esperando el evento "unidad de disco liberada", lo cual solo puede ser causada por alguno de los otros procesos en espera. Este ejemplo ilustra un abrazo mortal involucrando procesos compitiendo por el mismo tipo de recurso. Los abrazos mortales pueden tambin involucrar diferentes tipos de recursos. Por ejemplo, consideremos un sistema con una impresora y una unidad de disco. Supongamos que el proceso A tiene asignada la unidad de disco y que el proceso B tiene asignada la impresora. Ahora, si A pide la impresora y B pide la unidad de disco, ocurre un abrazo mortal.

Ejemplo de un abrazo mortal. Es obvio que un abrazo mortal es una condicin indeseable. En un abrazo mortal, los procesos nunca terminan de ejecutarse y los recursos del sistema estn amarrados, evitando que otros procesos puedan siquiera empezar. Condiciones Necesarias . Una situacin de abrazo mortal puede surgir s y solo s las siguientes cuatro condiciones ocurren simultneamente en un sistema:

Exclusin Mutua. Cada recurso se asigna por lo regular exactamente a un proceso o bien esta disponible. Al menos un recurso es mantenido en un modo no-compartible; esto es, slo un proceso a la vez puede usar el recurso. Si otro proceso solicita ese recurso, tiene que ser retardado hasta que el recurso haya sido liberado. Retener y Esperar. Los procesos que regularmente contienen recursos otorgados antes pueden solicitar nuevos recursos. Debe existir un proceso que retenga al menos un recurso y est esperando para adquirir recursos adicionales que estn siendo retenidos por otros procesos. No existe el derecho de desasignar : Los recursos previamente otorgados no pueden extraerse por la fuerza de un proceso. Deben ser liberados explcitamente por el proceso que los contiene. Los recursos no pueden ser desasignados ; esto es, un recurso slo puede ser liberado voluntariamente por el proceso que lo retiene, despus de que el proceso ha terminado su tarea. Espera Circular. Debe haber una cadena de dos o ms procesos, cada uno de los cuales est esperando un recurso contenido en el siguiente miembro de la cadena. Debe existir un conjunto {p0, p1, ...,pn} de procesos en espera tal que p0 est esperando por un recurso que est siendo retenido por p1, p1 est esperando por un recurso que est siendo retenido por p2, ..., pn-1 est esperando por un recurso que est siendo retenido por pn y pn est esperando por un recurso que est siendo retenido por p0.

Se remarca que las cuatro condiciones deben de cumplirse para que pueda ocurrir un abrazo mortal. La condicin de espera circular implica la condicin de retener y esperar, de tal manera que las cuatro condiciones no son totalmente independientes. Sin embargo, puede ser til el considerar cada condicin por separado. Una forma de modelar estas condiciones es usando un grafo de recursos: los crculos representan procesos, los cuadrados recursos. Una arista desde un recurso a un proceso indica que el recurso ha sido asignado al proceso. Una arista desde un proceso a un recurso indica que el proceso ha solicitado el recurso, y est bloqueado esperndolo. Entonces, si hacemos el grafo con todos lo procesos y todos los recursos del sistema y encontramos un ciclo, los procesos en el ciclo estn bajo bloqueo mutuo.

Ejemplo de un grafo de recursos.

La discusin del control de concurrencia hasta aqu se ha centralizado alrededor del problema de que hacer cuando mltiples usuarios quieren actualizar el mismo archivo. Una manera completamente diferente es prevenir todas las actualizaciones. Desde este punto de vista, los archivos son inmutables; una vez que se crea un archivo no puede modificarse. En este caso, para incorporar nueva informacion en el archivo, un cliente puede crear una nueva versin del archivo que reemplaza (pero no modifica) el original. De esta manera, un archivo se vuelve una secuencia de versiones inmutables. La sincronizacin entre procesos es necesaria para prevenir y corregir errores de sincronizacin debidos al acceso concurrente de recursos compartidos, tales como estructuras de datos o dispositivos de E/S, de procesos contendientes. La sincronizacin entre procesos tambin permite intercambiar seales de tiempo entre procesos cooperantes para garantizar las relaciones especficas de precedencia impuestas por el problema que se resuelva. Sin una sincronizacin adecuada entre procesos, la actualizacin entre variables compartidas puede inducir a errores de tiempo relacionadas con la concurrencia que son con frecuencia difciles de depurar. Una de las causas principales de este problema es que procesos concurrentes puedan tener valores temporalmente inconsistentes de una variable compartida mientras se actualizan. Los semforos son un mecanismo sencillo pero poderoso de sincronizacin entre procesos. Los semforos satisfacen la mayora de los requerimientos que hemos especificado para un buen mecanismo de control de concurrencia, sin incluir suposiciones sobre las velocidades y prioridades relativas de los procesos contendientes y sin saber nada sobre los otros contendientes excepto que existen probablemente. Mediante el uso de semforos se pueden resolver algunos problemas bien conocidos de sincronizacin, como los de PRODUCTOR/CONSUMIDOR y LECTORES/ESCRITORES. Sincronizacin entre procesos La ejecucin concurrente de procesos, puede producir mejoras significativas de rendimiento respecto a la ejecucin secuencial de programas. Cuando es critico el rendimiento, se puede dividir el trabajo en varios procesos cooperantes definidos por el programador para explotar la posible concurrencia de un programa o aplicacin dada. Sin embargo, para que funcione apropiadamente un grupo de procesos, se deben sincronizar sus actividades de forma que asegure la observancia de las relaciones de precedencia dictadas por el problema que se est resolviendo. La sincronizacin entre procesos es necesaria para preservar la integridad del sistema y prevenir problemas de tiempo producidos por el acceso concurrente a recursos compartidos por mltiples procesos. En general, los procesos cooperantes deben sincronizarse siempre que intenten usar recursos compartidos por varios de ellos, tales como estructuras de datos o dispositivos fsicos comunes. El fallo en diseo de protocolos apropiados de sincronizacin y en obligar su uso por cada proceso que utiliza recursos comunes, produce frecuentemente un comportamiento errneo del sistema y rupturas que son notablemente difciles de depurar. La concurrencia puede producir un incremento de la productividad cuando se implementan correctamente, pero puede tambin degradar la fiabilidad cuando la sincronizacin impropia entre procesos contamina el sistema con errores artificios de tiempo.

http://boards4.melodysoft.com/2005AAA0203/transacciones-87.html