Universidad Privada Jos Carlos Maritegui Ingeniera de Sistemas E Informtica

Curso: Desarrollo Cliente- Servidor

INDICE

INDICE ................................ ................................ ................................ ................................ .... 1 INTRODUCCION ................................ ................................ ................................ ................... 2 THREE - PHASE COMMIT (3PC) ................................ ................................ .......................... 3 1. Descripcin del protocolo ................................ ................................ ......................... 3 1.1 Coordinador ................................ ................................ ................................ .............. 4 1.2 Participante ................................ ................................ ................................ ................ 5 2. Protocolo de Compromiso de 3 Fases ................................ ................................ ... 6 2.1 FASE 1: (de Votacin igual al Protocolo de 2PC): ................................ ............. 7 2.2 FASE 2: ................................ ................................ ................................ .......................... 7 2.3 FASE 3: Esta fase se ejecuta solamente si la decisin de la Fase 2 fue de precompromiso. ................................ ................................ ................................ .................. 7 3. 4. 5. 6. 8. 9. Manejo de Fallos en3PC ................................ ................................ ............................ 9 Protocolo de Fallo del Coordinador ................................ ................................ ..... 10 3PC - Estado de T ................................ ................................ ................................ ...... 10 3PC - La decisin de Cnew ................................ ................................ ..................... 10 Comparando 2PC y3PC ................................ ................................ .......................... 11 PC de 2 Fases vs. PC de 3 Fases ................................ ................................ ............. 12

BIBLIOGRAFIA ................................ ................................ ................................ ..................... 12

Docente: Ing. Yuri Romn Lazarinos

Universidad Privada Jos Carlos Maritegui Ingeniera de Sistemas E Informtica

Curso: Desarrollo Cliente- Servidor

INTRODUCCION

El protocolo

3PC, controla la ejecucin de una transaccin distribuida. La

transaccin distribuida se inicia en un determinado nodo que posee un SGBD participante en la distribucin -llamado el Coordinador -. Para la ejecucin de la transaccin, se preci sa emitir o difundir partes de las operaciones a otros nodos donde residen otros SGBDs -llamados Participantes - que son los encargados del acceso a los datos ubicados en cada localidad (flechas con nmero 2 en la figura 1). Cada Participante responde a la solicitud del Coordinador, indicando si est o no dispuesto para llevar a cabo su correspondiente transaccin local. Con esta informacin de control, recibida de los Participantes, el Coordinador adopta una decisin unnime de si ha de llevarse a cabo la t ransaccin o no, y se la difunde a todos los Participantes.

El papel de Coordinador o de Participante que puede jugar un determinado nodo, es eventual en cada ejecucin. Ser Coordinador el nodo que vaya a hacerse cargo de dirigir la ejecucin de dicha transaccin, y ser Participante aquel nodo encargado del acceso a los datos de su localidad participante.

Docente: Ing. Yuri Romn Lazarinos

Universidad Privada Jos Carlos Maritegui Ingeniera de Sistemas E Informtica

Curso: Desarrollo Cliente- Servidor

THREE - PHASE COMMIT (3PC)

Para facilitar la descripcin de los protocolos de confiabilidad distribuida se supondr que en el nodo que se origina una transaccin hay un proceso, llamado el coordinador, que ejecuta las operaciones de la transaccin. El coordinador se comunica con procesos participantes en los otros nodos los cuales lo ayudan en las operaciones de la transaccin. El protocolo 3PC fue originalmente descrito por Dale Skeen y Michael Sonebraker en su artculo "A Formal Model of Crash Recovery in a Distributed System." En este trabajo, ellos modelaron 2PC como un sistema de "mquina de estado finito no determin stica" y probaron que no es resistente a un fallo aleatorio de un nico nodo. La observacin bsica es que en 2PC, mientras un nodo est en el estado de "preparado para commit", el otro puede estar tanto en el estado de "commit" como en el de "abortar". A partir de este anlisis, desarrollaron 3PC para evitar dichos estados y por tanto ser resistente a dichos fallos.

1. Descripcin del protocolo

Para describir el protocolo usaremos una terminologa similar a la utilizada en el protocolo de commit de dos fases El 3PC es un algoritmo distribuido el cual hace que todos los nodos de un sistema distribuido hagan commit de una transaccin. Es una alternativa al 2PC. El 2PC es un algoritmo bloqueante mientras que el 3pc es un algoritmo no bloqueante. En el 2PC un nodo permanecer bloqueado esperando por un mensaje. Otro proceso puede estar esperando por los recursos que el proceso tiene bloqueados. Se pueden dar bloqueos indefinidos si el coordinador el participante falla. 3PC pone un lmite superior a la cantidad de tiempo necesario antes de un commit abort. Esta propiedad asegura que si una determinada transaccin va a hacer commit y tiene algunos recursos bloqueados, libera los bloqueos transcurrido ese tiempo. Por tanto tenemos un nico nodo coordinador lidera ndo la transaccin y un grupo de uno o ms participantes que son dirigidos por el coordinador.

Docente: Ing. Yuri Romn Lazarinos

Universidad Privada Jos Carlos Maritegui Ingeniera de Sistemas E Informtica

Curso: Desarrollo Cliente- Servidor

1.1 Coordinador

Diagrama de estados del coordinador

1. El coordinador recibe una solicitud de transaccin. Si hay un fallo en este momento, el coordinador aborta la transaccion (en cuanto se recupere hace la transicin por fallo). En caso contrario, el coordinador enva un mensaje de inicio de transaccin a los participantes y cambia al estado de en espera. 2. Si hay un fallo, timeout, o si el coordinador recibe un mensaje de no se iniciar la transaccin en el estado de en espera, el coordinador aborta la transaccin y enva un mensaje de abortar a todos los participantes. En caso contrario el coordinador recibir mensajes de puede comenzar la transaccin desde todos los participantes dentro de la ventana de tiempo, y por tanto enva mensajes de commit a todos los participantes y cambia al estado de preparados. 3. Si el coordinador falla en el estado de preparados , cambiar al estado de commit. Sin embargo si el coordinador se pasa de tiempo mientras espera un un reconocimiento de un participante, abortar la transaccin. En el caso de que todos los reconocimientos son recibidos, el coordinador cambia tambin al estado de commit.

Docente: Ing. Yuri Romn Lazarinos

Universidad Privada Jos Carlos Maritegui Ingeniera de Sistemas E Informtica

Curso: Desarrollo Cliente- Servidor

1.2 Participante

Diagrama de estados del participante

1. El participante recibe un mensaje de inicio de transaccin desde el coordinador. Si el participante est de acuerdo, contesta con un mensaje de se iniciar la transaccin (OK) al coordinador, y cambia al estado de en espera. En caso contrario enva un mensaje de no se iniciar la transaccin y aborta. Si hay un fallo, cambia al estado de abortar. 2. En el estado de en espera, si el participante recibe un mensaje de abortar desde el coordinador, tiene un fallo, o se pasa de tiempo esperando un commit, aborta. Si el participante recibe un mensaje de preparado , contesta con un mensaje ack y pasa al estado de pendiente . 3. Una vez en el estado de pendiente , al recibir un mensaje de commit , hace el commit. En caso de fallo o de timeout tambin hace commit.

Docente: Ing. Yuri Romn Lazarinos

Universidad Privada Jos Carlos Maritegui Ingeniera de Sistemas E Informtica

Curso: Desarrollo Cliente- Servidor

Incluye una nueva fase llamada Pre -Commit.

Cuando se recibe un mensaje de pre-commit, el participante conoce que todos los dems han votado por commit. Si el mensaje de precommit no es recibido el participante aborta y libera los recursos bloqueados.

2. Protocolo de Compromiso de 3 Fases

El protocolo de compromiso de 3 fases evita la posibilidad de bloqueos en para un subconjunto restringido de posibles fallos. El protocolo de compromiso de 3 fases exige que: No ocurran particiones de la red (para que en caso de fallos, se pueda elegir un nuevo coordinador). A lo sumo k sitios partici pantes pueden fallar mientras se ejecuta el protocolo. k es un parmetro que mide la tolerancia a los fallos. En cualquier momento, debe haber al menos k+1 sitios funcionando correctamente. Para evitar bloqueos, se agrega una fase en la cual se alcanza una decisin preliminar sobre el destino de T.

Docente: Ing. Yuri Romn Lazarinos

Universidad Privada Jos Carlos Maritegui Ingeniera de Sistemas E Informtica

Curso: Desarrollo Cliente- Servidor

2.1 FASE 1: (de Votacin igual al Protocolo de 2PC):

y y y y y

Ci agrega el registro <prepare T> a la bitcora y lo graba en memoria estable. Ci enva un mensaje prepare T a todos los sitios donde se ejecut T. Cada gestor que recibe el mensaje determina si puede o no cometer su porcin de T. Respuesta Si: agrega <ready T> a la bitcora, la graba en memoria estable y enva el mensaje ready T a Ci. Respuesta No: agrega <no T> a la bitcora, la graba en memoria estable y enva el mensaje abort T a Ci

2.2 FASE 2:

Si Ci recibe un mensaje "no T" de un participante o si no recibe respuesta (en cierto perodo), decide abortar T y enva el mensaje "abort T" a todos los participantes. Si Ci recibe un mensaje "ready T" de cada sitio participante, toma la decisin preliminar de pre - compromiso, grabando en bitcora <precommit T> y enva el mensaje "precommit T" a todos los participantes. Cuando un participante recibe el mensaje de aborto o pre compromiso graba en bitcora di cho mensaje (<abort> o <precommit>) y enva el mensaje "acknowledge T" al coordinador.

2.3 FASE 3: Esta fase se ejecuta solamente si la decisin de la Fase 2 fue de precompromiso.
y

y y y

Despus de que se enviaron los respectivos mensajes "precommit T" a todos los participantes, debe esperar que al menos k sitios enven el mensaje "acknowledge T". Recien en ese momento, el coordinador decide cometer grabando en bitcora <commit T> y enviando un mensaje "commit T" a cada uno de los participantes. Cuando cada participante recibe ese mensaje, lo graba en su respectiva bitcora Como en el 2PC, un sitio que puede decidir abortar T enviando un mensaje "abort T" antes del "ready T". Mientras que en el2PC el coordinador puede incondicionalmente abortar T antes de enviar el mensaje "commit T", el mensaje "precommit T" es una promesa del coordinador de que eventualmente se cometer T.

Docente: Ing. Yuri Romn Lazarinos

Universidad Privada Jos Carlos Maritegui Ingeniera de Sistemas E Informtica

Curso: Desarrollo Cliente- Servidor

y y

La fase 3 de este protocolo lleva a una decisin de commit por lo que parece de poca utilidad prctica. El rol de la fase 3 se justifica en caso de fallos.

El protocolo de compromiso de 3 fases evita la posibilidad de bloqueos siempre que se restrinja el nmero de fallas posibles (algo muy difcil de garantizar). El protocolo de compromiso de 3 fases exige que:
y y

No ocurran particiones de la red (para que en caso de fallos, se pueda elegir un nuevo coordinador). A lo sumo k sitios participantes pueden fallar mientras se ejecuta el protocolo. k es un parmetro que mide la tolerancia a los fallos.

Docente: Ing. Yuri Romn Lazarinos

Universidad Privada Jos Carlos Maritegui Ingeniera de Sistemas E Informtica

Curso: Desarrollo Cliente- Servidor

y y

En cualquier momento, debe haber al menos k+1 sitios funcionando correctamente. Para evitar bloqueos, se agrega una fase en la cual se alcanza una decisin preliminar sobre el destino de T

3. Manejo de Fallos en3PC

     

Fallo de un participante Tareas del coordinador cuando detecta el fallo de un participante. Tareas del participante como parte del proceso de recuperacin. Fallo del coordinador Seleccin de un nuevo coordinador entre los participantes. Tareas del coordinador como parte del proceso de recuperacin.

a) Fallo de un Participante
Qu hace un participante como parte del proceso de recuperacin? Si Ti falla antes de enviar al coordinador un mensaje Ready T, el coordinador alcanza su timeout y aborta T.
y

Si Ti falla despus de enviar al coordinador un mensaje Ready T, el coordinador ignora la falla de Ti

y y y

Si contiene un <commit T> en su bitcora, ejecutar Redo(T). Si contiene un <abort T> en su bitcora, ejecutar Undo(T). Si contiene un <precommit T> pero no un <abort T> ni un <commit T> consulta con Ci y ejecuta Undo(T) si recibe el mens aje "abort T" y Redo(T) si recibe un "commit T".

Si contiene un <ready T> pero no un <abort T> ni un <precommit T> consulta con Ci

Si contiene un <ready T> pero no un <abort T> ni un <precommit T> consulta con Ci.

y y y

Si Ci responde que "abort T", ejecuta Un do(T). Si Ci responde que "commit T", ejecuta Redo(T). Si Ci responde que "precommit T", graba el registro <precommit T> en su bitcora y enva un mensaje "acknowledge T" al Ci.

Si Ci no responde se ejecuta el protocolo de fallo del Ci.

Docente: Ing. Yuri Romn Lazarinos

Universidad Privada Jos Carlos Maritegui Ingeniera de Sistemas E Informtica

Curso: Desarrollo Cliente- Servidor

b) Fallo del coordinador

y y y

Si un participante, por cualquier motivo no recibe respuesta del coordinador, dispara el protocolo de fallo de coordinador. El resultado ser la seleccin de un nuevo coordinador. Cuando el coordinador fallado se recupera, seguir actuando como participante, acatando las decisiones del nuevo coordinador.

4. Protocolo de Fallo del Coordinador

1. Los sitios participantes activos seleccionan un nuevo coordinador. 2. El nuevo coordinador Cnew enva un mensaje a cada sitio participante requiriendo el estado local de T. 3. Cada sitio participante (incluyendo Cnew) determina el estado local de T (cometida, abortada, lista, precometida, no lista). 4. Dependiendo de las respuestas recibidas, Cnew decide si cometer o abortar T.

5. 3PC - Estado de T Cometida: la bitcora contiene un registro <commit T>. Abortada: la bitcora contiene un registro <abort T>. Lista: la bitcora contiene un <ready T> pero no contiene un <abort T> ni un <precommit T>. Precometida: la bitcora contiene un registro <precommi t T> pero no contiene un registro <abort T> ni un registro <commit T>. No Lista: la bitcora no contiene un <ready T> ni un <abort T>. 6. 3PC - La decisin de Cnew

Si al menos un sitio tiene el estado cometido, entonces Cnew decide cometer T.

Si al menos un sitio tiene el estado abortado, entonces Cnew decide abortar T.

10

Docente: Ing. Yuri Romn Lazarinos

Universidad Privada Jos Carlos Maritegui Ingeniera de Sistemas E Informtica

Curso: Desarrollo Cliente- Servidor

Si ningn sitio est cometido o abortado pero existe al menos un sitio en estado precometido, Cnew reanuda el protocolo enviando un nuevo mensaje de pre- compromiso.

y y

En otro caso, Cnew aborta T. El nuevo coordinador Cnew puede llegar a conocer el estado del coordinador fallado Ci.

Si un sitio activo tiene un <commit T> en su bitcora, entonces Ci tiene que haber decidido cometer T.

Si un sitio activo tiene un <precommit T> en su bitcora, ento nces Ci alcanz un estado de pre- compromiso, lo que implica que todos los sitios alcanzaron el estado de listos.

A diferencia del PC de 2 Fases, Cnew no comete T unilateralmente ya que puede producir un bloqueo si Cnew falla.

7. Qu pasa si ningn sitio activo recibi el mensaje de pre -compromiso de Ci?

y y y y

Ci ha decidido cometer antes de fallar. Ci ha decidio abortar antes de fallar. Ci no ha decidido sobre la suerte de T. La primera alternativa no es posible y, por lo tanto, veremos que es seguro abortar.

Si Ci decidi cometer, entonces al menos k sitios decidieron pre cometer T y enviaron un reconocimiento (acknowledge) a Ci.

Por lo tanto, existen al menos k sitios activos y al menos uno de ellos debe informar a Cnew que recibi un mensaje de pre -compromiso.

Si ningun sitio activo recibi un mensaje de pre -compromiso, no esposible que Ci haya decidido cometer.

8. Comparando 2PC y3PC

Ambos protocolos buscan satisfacer el principio de atomicidad: una transaccin se ejecuta en su totalidad o no se ejecuta por co mpleto.

11

Docente: Ing. Yuri Romn Lazarinos

Universidad Privada Jos Carlos Maritegui Ingeniera de Sistemas E Informtica

Curso: Desarrollo Cliente- Servidor

Ambos asumen ciertas condiciones en la red: que no se pierden mensajes y que los mensajes llegan en el mismo orden en que fueron enviados. El PC de 3 Fases exige condiciones adicionales como por ejemplo, que la red no pueda particionarse en dos o m s grupos que no se pueden comunicar entre si. El Protocolo de Compromiso de 2 Fases puede dejar bloqueada a una transaccin, ya que el destino de una transaccin no se conoce hasta que el sitio fallado (coordinador) no se recupera. El Protocolo de Compromiso de 3 Fases evita situaciones de bloqueo pero requiere un mayor trfico de mensajes.

9. PC de 2 Fases vs. PC de 3 Fases

Intuitivamente, el PC de 2 Fases permite que un participante cometa T ni bien descubre que los participantes votaron <commit T>. En cambio, en el PC de 3 Fases un participante comete T no slo cuando sabe que los participantes han votado <commit T>, sino tambin cuando conozca que todos los participantes saben eso (si alguno falla, lo deber saber cuando se recupere). Ms all de eso, el PC de 2 Fases es ms comnmente usado a pesar de sus bloqueos potenciales ya que la probabilidad de que stos ocurran es suficientemente baja con respecto al costo extra que insume la tercera fase en el PC de 3 Fases.

BIBLIOGRAFIA
 http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/M

onogSO/TRANS02.htm
 http://sinbad.dit.upm.es/docencia/grado/curso0304/Apuntes%202PC%2

0y%20Fiabilidad.pdf
 http://html.rincondelvago.com/bases -de-datos-distribuidas_2.html  http://es.wikipedia.org/wiki/Commit_de_tres_fases

12

Docente: Ing. Yuri Romn Lazarinos