Un sistema distribuido consta de varios
procesadores. Estos se pueden organizar como colección de estaciones de trabajo
personales, una pila pública de procesadores o alguna forma híbrida. En todos
los casos, se necesita cierto algoritmo para decidir cuál proceso hay que
ejecutar y en qué máquina. Para el modelo de estaciones de trabajo, la pregunta
es cuándo ejecutar el proceso de manera local y cuándo buscar una estación
inactiva. Para el modelo de la pila de procesadores, hay que tomar una decisión
por cada nuevo proceso.
En cuarto lugar, cada maquina puede tener un sistema de archivos auto contenido, con la posibilidad de montarlo o tener su sistema de archivos de otras maquinas. La idea aquí es que cada maquina esta auto contenida en lo fundamental y que el contacto con el mundo exterior sea limitado. Este sistema proporciona un tiempo de respuesta uniforme y garantizada para el usuario y pone poca carga en la red.
En cuarto lugar, cada maquina puede tener un sistema de archivos auto contenido, con la posibilidad de montarlo o tener su sistema de archivos de otras maquinas. La idea aquí es que cada maquina esta auto contenida en lo fundamental y que el contacto con el mundo exterior sea limitado. Este sistema proporciona un tiempo de respuesta uniforme y garantizada para el usuario y pone poca carga en la red.
Uso de estaciones de trabajo inactivas
Plantea el problema de encontrar estaciones de trabajo inactivas en la red que puedan ejecutar procesos. Por lo cual las estaciones de trabajo deben de anunciar cuando no cuentan con una carga de trabajo asignada, así todas las demás estaciones toman nota de esto y lo registran.
Ya sea que existan muchos o pocos registros, existe un peligro potencial de que aparezcan condiciones de competencia si dos usuarios llaman al mismo tiempo al comando remote y ambos descubren que la misma maquina esta inactiva, ambos intentaran iniciar procesos al mismo tiempo. Para detectar y evitar esta situación, el programa remote verifica la estación de trabajo inactiva, la cual si continua libre se elimina así misma del registro y da la señal de continuar, de esta manera quien hizo la llamada puede enviar su ambiente e iniciar el proceso remoto.
Modelo de pila de procesadores
Este método consiste en construir una pila de procesadores, repleta de CPU, en un cuarto de maquinas, los cuales se pueden asignar de manera dinámica a los usuarios según la demanda.
Desde el punto de vista conceptual este método es mas parecido al tiempo compartido tradicional que al modelo de la computadora personal aunque se construye con la tecnología moderna. La motivación para la idea de la pila de procesadores proviene de dar un paso mas adelante en la idea de las estaciones de trabajo sin disco. Si el sistema de archivos se debe concentrar en un pequeño numero de servidores de archivos para mayor economía, debe ser posible hacer lo mismo con los servidores de computo, es decir si colocamos todos los CPU en un gabinete de gran tamaño en el cuarto de maquinas se pueden reducir los costos de suministro de energía y de empaquetamiento, lo cual produce un mayor poder de computo con una cantidad fija de dinero.
De hecho convertimos todo el poder de cómputo en “estaciones de trabajo inactivas” a las que se puede tener acceso de manera dinámica. Los usuarios obtienen tantos CPU como sea necesario, durante periodos cortos, después de lo cual regresan a la pila, de modo que otros usuarios puedan disponer de ellos.
Plantea el problema de encontrar estaciones de trabajo inactivas en la red que puedan ejecutar procesos. Por lo cual las estaciones de trabajo deben de anunciar cuando no cuentan con una carga de trabajo asignada, así todas las demás estaciones toman nota de esto y lo registran.
Ya sea que existan muchos o pocos registros, existe un peligro potencial de que aparezcan condiciones de competencia si dos usuarios llaman al mismo tiempo al comando remote y ambos descubren que la misma maquina esta inactiva, ambos intentaran iniciar procesos al mismo tiempo. Para detectar y evitar esta situación, el programa remote verifica la estación de trabajo inactiva, la cual si continua libre se elimina así misma del registro y da la señal de continuar, de esta manera quien hizo la llamada puede enviar su ambiente e iniciar el proceso remoto.
Modelo de pila de procesadores
Este método consiste en construir una pila de procesadores, repleta de CPU, en un cuarto de maquinas, los cuales se pueden asignar de manera dinámica a los usuarios según la demanda.
Desde el punto de vista conceptual este método es mas parecido al tiempo compartido tradicional que al modelo de la computadora personal aunque se construye con la tecnología moderna. La motivación para la idea de la pila de procesadores proviene de dar un paso mas adelante en la idea de las estaciones de trabajo sin disco. Si el sistema de archivos se debe concentrar en un pequeño numero de servidores de archivos para mayor economía, debe ser posible hacer lo mismo con los servidores de computo, es decir si colocamos todos los CPU en un gabinete de gran tamaño en el cuarto de maquinas se pueden reducir los costos de suministro de energía y de empaquetamiento, lo cual produce un mayor poder de computo con una cantidad fija de dinero.
De hecho convertimos todo el poder de cómputo en “estaciones de trabajo inactivas” a las que se puede tener acceso de manera dinámica. Los usuarios obtienen tantos CPU como sea necesario, durante periodos cortos, después de lo cual regresan a la pila, de modo que otros usuarios puedan disponer de ellos.
Algoritmos o Modelos de Asignación
Los
algoritmos deterministas son adecuados cuando se sabe anticipadamente todo
acerca del comportamiento de los procesos, pero esto generalmente no se da,
aunque puede haber en ciertos casos aproximaciones estadísticas. Los algoritmos
heurísticos son adecuados cuando la carga es impredecible.
Los diseños centralizados permiten reunir toda la información en un lugar y tomar una mejor decisión; la desventaja es que la máquina central se puede sobrecargar y se pierde robustez ante su posible falla.
Generalmente los algoritmos óptimos consumen más recursos que los sub-óptimos, además, en la mayoría de los sistemas reales se buscan soluciones sub-óptimas, heurísticas y distribuidas.
Cuando se va a crear un proceso se debe decidir si se ejecutará en la máquina que lo genera o en otra (política de transferencia):
La decisión se puede tomar “solo con información local” o “con información global”.
Los algoritmos locales son sencillos pero no óptimos.
Los algoritmos globales son mejores pero consumen muchos recursos.
Cuando una máquina se deshace de un proceso la política de localización debe decidir dónde enviarlo:
Necesita información de la carga en todas partes, obteniéndola de:
Un emisor sobrecargado que busca una máquina inactiva.
Un receptor desocupado que busca trabajo.
‘’Aspectos de la Implantación de Algoritmos de Asignación de Procesadores’‘
Casi todos los algoritmos suponen que las máquinas conocen su propia carga y que pueden informar su estado:
La medición de la carga no es tan sencilla.
Un método consiste en contar el número de procesos (hay que considerar los procesos latentes no activos). Otro método consiste en contar solo los procesos en ejecución o listos.
También se puede medir la fracción de tiempo que la cpu está ocupada.
Otro aspecto importante es el costo excesivo en consumo de recursos para recolectar medidas y desplazar procesos, ya que se debería considerar el tiempo de cpu, el uso de memoria y el ancho de banda de la red utilizada por el algoritmo para asignación de procesadores.
Se debe considerar la complejidad del software en cuestión y sus implicancias para el desempeño, la correctez y la robustez del sistema.
Si el uso de un algoritmo sencillo proporciona casi la misma ganancia que uno más caro y más complejo, generalmente será mejor utilizar el más sencillo.
Se debe otorgar gran importancia a la estabilidad del sistema:
Las máquinas ejecutan sus algoritmos en forma asíncrona por lo que el sistema nunca se equilibra.
La mayoría de los algoritmos que intercambian información:
Son correctos luego de intercambiar la información y de que todo se ha registrado.
Son poco confiables mientras las tablas continúan su actualización, es decir que se presentan situaciones de no equilibrio.
Modelos de Asignación
Generalmente se utilizan las siguientes hipótesis:
-Todas las máquinas son idénticas (o al menos compatibles en el código); difieren a lo sumo en la velocidad.
-Cada procesador se puede comunicar con los demás.
Las estrategias de asignación de procesadores se dividen en:
-No migratorias:
Una vez colocado un proceso en una máquina permanece ahí hasta que termina.
-Migratorias:
Un proceso se puede trasladar aunque haya iniciado su ejecución.
Permiten un mejor balance de la carga pero son más complejas.
Los algoritmos de asignación intentan optimizar algo:
-Uso de las cpu:
Maximizar el número de ciclos de cpu que se ejecutan para trabajos de los usuarios.
Minimizar el tiempo de inactividad de las cpu.
-Tiempo promedio de respuesta:
Minimizar no los tiempos individuales de respuesta sino los tiempos promedio de respuesta.
-Tasa de respuesta:
Minimizar la tasa de respuesta, que es el tiempo necesario para ejecutar un proceso en cierta máquina dividido por el tiempo que tardaría en cierto procesador de referencia.
Los diseños centralizados permiten reunir toda la información en un lugar y tomar una mejor decisión; la desventaja es que la máquina central se puede sobrecargar y se pierde robustez ante su posible falla.
Generalmente los algoritmos óptimos consumen más recursos que los sub-óptimos, además, en la mayoría de los sistemas reales se buscan soluciones sub-óptimas, heurísticas y distribuidas.
Cuando se va a crear un proceso se debe decidir si se ejecutará en la máquina que lo genera o en otra (política de transferencia):
La decisión se puede tomar “solo con información local” o “con información global”.
Los algoritmos locales son sencillos pero no óptimos.
Los algoritmos globales son mejores pero consumen muchos recursos.
Cuando una máquina se deshace de un proceso la política de localización debe decidir dónde enviarlo:
Necesita información de la carga en todas partes, obteniéndola de:
Un emisor sobrecargado que busca una máquina inactiva.
Un receptor desocupado que busca trabajo.
‘’Aspectos de la Implantación de Algoritmos de Asignación de Procesadores’‘
Casi todos los algoritmos suponen que las máquinas conocen su propia carga y que pueden informar su estado:
La medición de la carga no es tan sencilla.
Un método consiste en contar el número de procesos (hay que considerar los procesos latentes no activos). Otro método consiste en contar solo los procesos en ejecución o listos.
También se puede medir la fracción de tiempo que la cpu está ocupada.
Otro aspecto importante es el costo excesivo en consumo de recursos para recolectar medidas y desplazar procesos, ya que se debería considerar el tiempo de cpu, el uso de memoria y el ancho de banda de la red utilizada por el algoritmo para asignación de procesadores.
Se debe considerar la complejidad del software en cuestión y sus implicancias para el desempeño, la correctez y la robustez del sistema.
Si el uso de un algoritmo sencillo proporciona casi la misma ganancia que uno más caro y más complejo, generalmente será mejor utilizar el más sencillo.
Se debe otorgar gran importancia a la estabilidad del sistema:
Las máquinas ejecutan sus algoritmos en forma asíncrona por lo que el sistema nunca se equilibra.
La mayoría de los algoritmos que intercambian información:
Son correctos luego de intercambiar la información y de que todo se ha registrado.
Son poco confiables mientras las tablas continúan su actualización, es decir que se presentan situaciones de no equilibrio.
Modelos de Asignación
Generalmente se utilizan las siguientes hipótesis:
-Todas las máquinas son idénticas (o al menos compatibles en el código); difieren a lo sumo en la velocidad.
-Cada procesador se puede comunicar con los demás.
Las estrategias de asignación de procesadores se dividen en:
-No migratorias:
Una vez colocado un proceso en una máquina permanece ahí hasta que termina.
-Migratorias:
Un proceso se puede trasladar aunque haya iniciado su ejecución.
Permiten un mejor balance de la carga pero son más complejas.
Los algoritmos de asignación intentan optimizar algo:
-Uso de las cpu:
Maximizar el número de ciclos de cpu que se ejecutan para trabajos de los usuarios.
Minimizar el tiempo de inactividad de las cpu.
-Tiempo promedio de respuesta:
Minimizar no los tiempos individuales de respuesta sino los tiempos promedio de respuesta.
-Tasa de respuesta:
Minimizar la tasa de respuesta, que es el tiempo necesario para ejecutar un proceso en cierta máquina dividido por el tiempo que tardaría en cierto procesador de referencia.
Planificación De Sistemas Distribuidos
No
hay mucho que decir de la planificación en los sistemas distribuidos. Por lo
general, cada procesador hace su planificación local (si tiene varios procesos
en ejecución), sin preocuparse por lo que hacen los demás procesadores. Lo
normal es que este método funcione. Sin embargo, si un grupo de procesos
relacionados entre sí y con gran interacción se ejecutan en distintos
procesadores, la planificación independiente no es el camino más eficiente.
La dificultad básica se puede mostrar mediante un ejemplo, en el cual los procesos A y B se ejecutan en un procesador y los procesos C y D en otro. El tiempo de cada procesador se comparte en pedazos de 100 milisegundos, donde A y C se ejecutan en los pedazos pares y B y D en los nones, como se muestra en la figura 4-20(a).
Supongamos que A envía muchos mensajes o lleva a cabo muchas llamadas a procedimientos remotos de D. Durante el tiempo 0, A inicia y llama de inmediato a D, que por desgracia no se ejecuta en ese momento, puesto que es el turno de C. Después de 100 milisegundos, se alternan los procesos, D obtiene el mensaje de A, lleva a cabo el trabajo y responde con rapidez. Puesto que B está ejecutándose, pasarán otros 100 milisegundos antes de que A obtenga la respuesta y pueda proseguir. El resultado neto es un intercambio de mensajes cada 200 milisegundos.
Lo que se necesita es una forma de garantizar que los procesos con comunicación frecuente se ejecuten de manera simultánea.
Aunque es difícil determinar en forma dinámica los patrones de común entre los procesos, en muchos casos, un grupo de procesos relacionados entre sí iniciarán juntos.
Por ejemplo, en general está bien suponer que los filtros de un entubamiento en UNIX se comunicarán entre sí más de lo qué lo harán con otros procesos ya iniciados.
Supongamos que los procesos se crean en grupos y que la comunicación dentro de los grupos prevalece sobre la comunicación entre los grupos. Supongamos además que se dispone de un número de procesadores lo bastante grande como para manejar al grupo de mayor tamaño y que cada procesador se multiprograma con N espacios para los procesos multiprogramación de nivel N).
La dificultad básica se puede mostrar mediante un ejemplo, en el cual los procesos A y B se ejecutan en un procesador y los procesos C y D en otro. El tiempo de cada procesador se comparte en pedazos de 100 milisegundos, donde A y C se ejecutan en los pedazos pares y B y D en los nones, como se muestra en la figura 4-20(a).
Supongamos que A envía muchos mensajes o lleva a cabo muchas llamadas a procedimientos remotos de D. Durante el tiempo 0, A inicia y llama de inmediato a D, que por desgracia no se ejecuta en ese momento, puesto que es el turno de C. Después de 100 milisegundos, se alternan los procesos, D obtiene el mensaje de A, lleva a cabo el trabajo y responde con rapidez. Puesto que B está ejecutándose, pasarán otros 100 milisegundos antes de que A obtenga la respuesta y pueda proseguir. El resultado neto es un intercambio de mensajes cada 200 milisegundos.
Lo que se necesita es una forma de garantizar que los procesos con comunicación frecuente se ejecuten de manera simultánea.
Aunque es difícil determinar en forma dinámica los patrones de común entre los procesos, en muchos casos, un grupo de procesos relacionados entre sí iniciarán juntos.
Por ejemplo, en general está bien suponer que los filtros de un entubamiento en UNIX se comunicarán entre sí más de lo qué lo harán con otros procesos ya iniciados.
Supongamos que los procesos se crean en grupos y que la comunicación dentro de los grupos prevalece sobre la comunicación entre los grupos. Supongamos además que se dispone de un número de procesadores lo bastante grande como para manejar al grupo de mayor tamaño y que cada procesador se multiprograma con N espacios para los procesos multiprogramación de nivel N).
Tolerancia a Fallas
La
promesa de los sistemas distribuidos sólo se puede cumplir cuando a la base
hardware adecuado se le añaden políticas y mecanismos tolerantes a fallas. El
objetivo del diseño y construcción de sistemas tolerantes a fallas consiste en
garantizar que el sistema continúe funcionando de manera correcta como un todo,
incluso en presencia de fallas.
Se dice que un sistema falla cuando no cumple su especificación. En algunos casos, como en un sistema de ordenamiento distribuido de productos en un supermercado, una falla podría provocar la falta de algunos productos en la tienda. En otros casos, como en un sistema distribuido para el control de tráfico aéreo, una falla podría ser catastrófica. Como las computadoras y los sistemas distribuidos se utilizan cada vez más en misiones donde la seguridad es crítica, la necesidad de soportar las fallas cada vez es mayor.
Un sistema consiste de un conjunto de componentes de hardware y software y son diseñados para proveer un servicio específico. Los componentes de un sistema pueden estar interrelacionados entre ellos. Un desperfecto de un sistema ocurre cuando el sistema no desempeña estos servicios de la manera especificada. Un estado erróneo en un sistema es un estado en el cual podría conducir a un fallo en el sistema. Un fallo es una condición física anormal, las causas de un fallo incluyen: errores de diseño (como errores en la especificación del sistema o en la implementación), problemas de fabricación, deterioro por el uso u otros problemas externos (como condiciones ambientales adversas, interferencia electromagnética, entradas imprevistas o el mal uso del sistema). Un error es una parte del estado del sistema la cual difiere de los valores esperados.
Un error del sistema puede ser visto como una manifestación de mal funcionamiento del sistema, el cual podría conducir a un fallo del sistema. Es necesario entonces, que el sistema sea capaz de recuperarse de las fallas, necesitamos deshacernos del estado de error del sistema, en otras palabras, la recuperación de un fallo, es un proceso que involucra la restauración de un estado erróneo a un estado libre de error.
Se dice que un sistema falla cuando no cumple su especificación. En algunos casos, como en un sistema de ordenamiento distribuido de productos en un supermercado, una falla podría provocar la falta de algunos productos en la tienda. En otros casos, como en un sistema distribuido para el control de tráfico aéreo, una falla podría ser catastrófica. Como las computadoras y los sistemas distribuidos se utilizan cada vez más en misiones donde la seguridad es crítica, la necesidad de soportar las fallas cada vez es mayor.
Un sistema consiste de un conjunto de componentes de hardware y software y son diseñados para proveer un servicio específico. Los componentes de un sistema pueden estar interrelacionados entre ellos. Un desperfecto de un sistema ocurre cuando el sistema no desempeña estos servicios de la manera especificada. Un estado erróneo en un sistema es un estado en el cual podría conducir a un fallo en el sistema. Un fallo es una condición física anormal, las causas de un fallo incluyen: errores de diseño (como errores en la especificación del sistema o en la implementación), problemas de fabricación, deterioro por el uso u otros problemas externos (como condiciones ambientales adversas, interferencia electromagnética, entradas imprevistas o el mal uso del sistema). Un error es una parte del estado del sistema la cual difiere de los valores esperados.
Un error del sistema puede ser visto como una manifestación de mal funcionamiento del sistema, el cual podría conducir a un fallo del sistema. Es necesario entonces, que el sistema sea capaz de recuperarse de las fallas, necesitamos deshacernos del estado de error del sistema, en otras palabras, la recuperación de un fallo, es un proceso que involucra la restauración de un estado erróneo a un estado libre de error.
Transacciones, Definición
Una
transacción es una colección de acciones que hacen transformaciones
consistentes de los estados de un sistema preservando la consistencia del
sistema. Una base de datos está en un estado consistente si obedece todas las
restricciones de integridad definidas sobre ella. Los cambios de estado ocurren
debido a actualizaciones, inserciones, y supresiones de información. Por
supuesto, se quiere asegurar que la base de datos nunca entra en un estado de
inconsistencia. Sin embargo, durante la ejecución de una transacción, la base
de datos puede estar temporalmente en un estado inconsistente. El punto
importante aquí es asegurar que la base de datos regresa a un estado
consistente al fin de la ejecución de una transacción
Lo que se persigue con el manejo de transacciones es por un lado tener una transparencia adecuada de las acciones concurrentes a una base de datos y por otro lado tener una transparencia adecuada en el manejo de las fallas que se pueden presentar en una base de datos.
Lo que se persigue con el manejo de transacciones es por un lado tener una transparencia adecuada de las acciones concurrentes a una base de datos y por otro lado tener una transparencia adecuada en el manejo de las fallas que se pueden presentar en una base de datos.
Aspectos relacionados al procesamiento de transacciones
Los
siguientes son los aspectos más importantes relacionados con el procesamiento de
transacciones:
1. Modelo de estructura de transacciones. Es importante considerar si las transacciones son planas o pueden estar anidadas.
2. Consistencia de la base de datos interna. Los algoritmos de control de datos semántico tienen que satisfacer siempre las restricciones de integridad cuando una transacción pretende hacer un commit.
3. Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir medios de comunicación entre los diferentes nodos de una red para garantizar la atomicidad y durabilidad de las transacciones. Así también, se requieren protocolos para la recuperación local y para efectuar los compromisos (commit) globales.
4. Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia deben sincronizar la ejecución de transacciones concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas.
5. Protocolos de control de réplicas. El control de réplicas se refiere a cómo garantizar la consistencia mutua de datos replicados. Por ejemplo se puede seguir la estrategia read-one-write-all (ROWA).
1. Modelo de estructura de transacciones. Es importante considerar si las transacciones son planas o pueden estar anidadas.
2. Consistencia de la base de datos interna. Los algoritmos de control de datos semántico tienen que satisfacer siempre las restricciones de integridad cuando una transacción pretende hacer un commit.
3. Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir medios de comunicación entre los diferentes nodos de una red para garantizar la atomicidad y durabilidad de las transacciones. Así también, se requieren protocolos para la recuperación local y para efectuar los compromisos (commit) globales.
4. Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia deben sincronizar la ejecución de transacciones concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas.
5. Protocolos de control de réplicas. El control de réplicas se refiere a cómo garantizar la consistencia mutua de datos replicados. Por ejemplo se puede seguir la estrategia read-one-write-all (ROWA).
Utilización de las Transacciones
Las
transacciones distribuidas abarcan dos o más servidores conocidos como
administradores de recursos. La administración de la transacción debe ser
coordinada entre los administradores de recursos mediante un componente de
servidor llamado administrador de transacciones. Cada instancia de SQL Server
Database Engine (Motor de base de datos de SQL Server) puede funcionar como
administrador de recursos en las transacciones distribuidas que coordinan los
administradores de transacciones, como el Coordinador de transacciones
distribuidas de Microsoft (MS DTC) u otros administradores que admitan la
especificación Open Group XA del procesamiento de transacciones distribuidas.
Para obtener más información, consulte la documentación de MS DTC.
Una transacción de una sola instancia de Database Engine (Motor de base de datos) que abarque dos o más bases de datos es, de hecho, una transacción distribuida. La instancia administra la transacción distribuida internamente; para el usuario funciona como una transacción local.
En la aplicación, una transacción distribuida se administra de forma muy parecida a una transacción local. Al final de la transacción, la aplicación pide que se confirme o se revierta la transacción. El administrador de transacciones debe administrar una confirmación distribuida de forma diferente para reducir al mínimo el riesgo de que, si se produce un error en la red, algunos administradores de recursos realicen confirmaciones mientras los demás revierten la transacción. Esto se consigue mediante la administración del proceso de confirmación en dos fases (la fase de preparación y la fase de confirmación), que se conoce como confirmación en dos fases (2PC).
Fase de preparación
Cuando el administrador de transacciones recibe una solicitud de confirmación, envía un comando de preparación a todos los administradores de recursos implicados en la transacción. Cada administrador de recursos hace lo necesario para que la transacción sea duradera y todos los búferes que contienen imágenes del registro de la transacción se pasan a disco. A medida que cada administrador de recursos completa la fase de preparación, notifica si la preparación ha tenido éxito o no al administrador de transacciones.
Fase de confirmación
Si el administrador de transacciones recibe la notificación de que todas las preparaciones son correctas por parte de todos los administradores de recursos, envía comandos de confirmación a cada administrador de recursos. A continuación, los administradores de recursos pueden completar la confirmación. Si todos los administradores de recursos indican que la confirmación ha sido correcta, el administrador de transacciones envía una notificación de éxito a la aplicación. Si algún administrador de recursos informó de un error al realizar la preparación, el administrador de transacciones envía un comando para revertir la transacción a cada administrador de recursos e indica a la aplicación que se ha producido un error de confirmación.
Las aplicaciones de Database Engine (Motor de base de datos) pueden administrar transacciones distribuidas a través de Transact-SQL o de la API de base de datos.
Una transacción de una sola instancia de Database Engine (Motor de base de datos) que abarque dos o más bases de datos es, de hecho, una transacción distribuida. La instancia administra la transacción distribuida internamente; para el usuario funciona como una transacción local.
En la aplicación, una transacción distribuida se administra de forma muy parecida a una transacción local. Al final de la transacción, la aplicación pide que se confirme o se revierta la transacción. El administrador de transacciones debe administrar una confirmación distribuida de forma diferente para reducir al mínimo el riesgo de que, si se produce un error en la red, algunos administradores de recursos realicen confirmaciones mientras los demás revierten la transacción. Esto se consigue mediante la administración del proceso de confirmación en dos fases (la fase de preparación y la fase de confirmación), que se conoce como confirmación en dos fases (2PC).
Fase de preparación
Cuando el administrador de transacciones recibe una solicitud de confirmación, envía un comando de preparación a todos los administradores de recursos implicados en la transacción. Cada administrador de recursos hace lo necesario para que la transacción sea duradera y todos los búferes que contienen imágenes del registro de la transacción se pasan a disco. A medida que cada administrador de recursos completa la fase de preparación, notifica si la preparación ha tenido éxito o no al administrador de transacciones.
Fase de confirmación
Si el administrador de transacciones recibe la notificación de que todas las preparaciones son correctas por parte de todos los administradores de recursos, envía comandos de confirmación a cada administrador de recursos. A continuación, los administradores de recursos pueden completar la confirmación. Si todos los administradores de recursos indican que la confirmación ha sido correcta, el administrador de transacciones envía una notificación de éxito a la aplicación. Si algún administrador de recursos informó de un error al realizar la preparación, el administrador de transacciones envía un comando para revertir la transacción a cada administrador de recursos e indica a la aplicación que se ha producido un error de confirmación.
Las aplicaciones de Database Engine (Motor de base de datos) pueden administrar transacciones distribuidas a través de Transact-SQL o de la API de base de datos.
No hay comentarios:
Publicar un comentario