Methodology

Como se ha indicado, el conjunto de procesos y subprocesos anteriores marcaron, en general, el comportamiento de modelo de simulación. Ahora bien, cada una de las alternativas a evaluar (esquemas propietario y de propagación) necesitaron consideraciones particulares en su implementación final y detallada. En esta sección se describen esas características.

Esquema de propagación Eager

El mecanismo de propagación Eager necesita actualizar simultáneamente todas las réplicas del dato modificado. De aquí que sea necesario implementar alguna técnica que garantice bloquear la información asegurando la exclusión mutua sobre el elemento de dato (en el capítulo 2 se abordó el tema en detalle).

Para decidir en detalle el comportamiento de los procesos de la sección 6.1.1. debe notarse la influencia que tendrá sobre el esquema de propagación

Eager el esquema propietario que se utilice. Si fuera Master-Slave se puede utilizar un mecanismo de control de concurrencia centralizado (solo se actúa sobre el sitio maestro). Por el contrario si el esquema propietario fuera Group, la decisión sobre obtener o no un dato debe tomarse de común acuerdo con todas las réplicas, un mecanismo como mayoría podría ser utilizado.

En el modelo de simulación realizado se introducen cambios en el proceso Propagador y el proceso Administrador de Datos, para permitir que los mismos simulen situaciones de espera en el acceso a los datos. Entonces, se agrega un tiempo de espera, que simula el acceso y liberación sobre un ítem de datos.

La simulación del bloqueo y liberación de un dato particular se logra a partir de primitivas de sincronización del lenguaje seleccionado. El proceso Administrador de Datos cuando quiere leer o actualizar un dato, realiza un cálculo aleatorio para determinar si el dato se encuentra o no bloqueado (en función de un parámetro de probabilidad de bloqueo definido previamente).

Simulación de los protocolos bloqueantes

Si se utilizara un protocolo de bloqueo se tendría un número de mensajes mayor o igual a 4n, si se replica la información en n nodos o sitios. [Bell et al, 1992]. Por este motivo se decidió, para el proceso de simulación generar una matriz de Peso de Comunicaciones que contiene un peso predefinible para las comunicaciones entre pares de sitios. Se calcula, utilizando esta matriz de Pesos el tiempo total de la demora que llevará la sincronización entre sitios. Básicamente el pseudo-código del cálculo de demora trabaja:

para cada nodo i {

si i-esimo nodo posee réplica del dato {

delay = delay + 4 * pesoComunicacion( nodoactual,i);

El proceso Propagador atiende sincrónicamente pedido por pedido, bloqueando los demás procesos involucrados. Así, ante una actualización, un subproceso Esclavo Emisor no recibe una respuesta desde el proceso Administrador de Datos hasta que se produzca la propagación.

Esquema de propagación Lazy

Como se discutió previamente en el capítulo 5, el esquema de propagación

lazy puede generar anomalías en la actualización de datos, debido a la demora en realizar las mismas. El proceso de simulación debe adaptarse para administrar estos casos, básicamente detectar y solucionar conflictos generados por la actualización de datos. La idea del protocolo de Hora de Entrada descripto en el capítulo 2 fue utilizado para garantizar que todas las réplicas de la “BD” converjan. Así, cada actualización solicitada sobre un dato lleva una marca e tiempo de cada réplica original. Si una marca de la réplica de un nodo viola el orden de escritura del dato entonces se genera un conflicto de actualización y es necesario, entonces, un mecanismo de reconciliación.

Se propone introducir a lo descripto en la sección 6.1.1. las variantes necesarias para utilizar las marcas de hora de entrada y un nuevo proceso denominado Recuperador encargado de administrar los mecanismos de reconciliación, más adelante se describe en detalle.

La marca de tiempo necesita ser generada en forma unívoca, independientemente del nodo donde se genera. El patrón utilizado es similar al descripto en el capítulo 2. Cada marca de tiempo se conforma con la concatenación de dos valores: (1) un valor único generado localmente, en este caso se utiliza la política de actualización acorde con el funcionamiento de los otros nodos (para evitar inanición en el proceso) y (2) la identificación del sitio que genera el pedido (el cual es único en la red). El comportamiento detallado de este método ya fue presentado anteriormente.

El proceso de actualización con esquemas de propagación lazy pueden generar conflictos, los cuales deben ser detectados y resueltos. El proceso Recuperador es activado por el proceso Administrador de Datos en caso de detectar un conflicto.

El proceso de actualización. Proceso Recuperador.

Primeramente se describe una situación de conflicto. Suponga que un dato X se encuentra replicado en el sitio ALFA y BETA. Dos transacciones Tα y Tβ se inician en, respectivamente, sus sitios y las dos intenten modificar el estado del dato X, a continuación se plantea el estado inicial:

Sitio ALFA Sitio BETA

Dato X Æ 1200

Última modificación Æ 3α

Dato X Æ 1200

Última modificación Æ 3α

Las dos transacciones generadas, Tα y Tβ, tiene las siguientes características:

Tα Tβ

Dato X (nuevo valor) Æ 1000 Marca de tiempo Æ 10α

Dato X (nuevo valor)Æ 1500 Marca de tiempo Æ 7β

De acuerdo al comportamiento de los procesos que intervienen en la actualización de la información ambas transacción actuarán sobre sus datos locales y luego propagarán hacia las otras réplicas la actualización realizada. El estado del esquema, luego que Tα y Tβ terminen ( y antes de propagar será):

Sitio ALFA Sitio BETA

Dato X Æ 1000

Última modificación Æ 10α

Dato X Æ 1500

Última modificación Æ 7β

Ahora, tanto alfa como beta activan el mecanismo de propagación, con lo que la actualización se lleva hacia los otros sitio, se intercambia la siguiente información:

Tα (propagada) Tβ (propagada) Dato X (nuevo valor) Æ 1000

Marca tiempo anterior Æ 3α Marca de tiempo Æ 10α

Dato X (nuevo valor)Æ 1500 Marca tiempo anterior Æ 3α Marca de tiempo Æ 7β

Se debe notar que en la propagación se envía un el nuevo valor, la marca de tiempo de la transacción que realiza la modificación del dato y la marca de tiempo antigua que tenía dicho dato. La finalidad de la misma es la siguiente: el proceso Propagador envía al proceso Receptor del sitio remoto la orden de actualización del dato X, el proceso Receptor pasa la solicitud al Administrador de Datos, este corrobora la marca de tiempo anterior recibida contra la marca actual del dato X, en caso que no haya coincidencia la causa es un conflicto que debe ser resuelto y la forma de resolverlo es invocar al proceso Recuperador.

En el caso planteado anteriormente se detecta la situación anómala y, por ende, se activa el proceso Recuperador. La forma de operación del mismo se define de acuerdo al mecanismo de reconciliación conocida como Thomas Write Rule [Bernstein et al., 1987]. Sucintamente, esta regla ignora la transacción con marca de tiempo menor, solo realiza los cambios de la marca mayor. De esta forma (sencilla) el conflicto queda resuelto. En el ejemplo planteado Tβ es ignorada y el Archivo de Datos de los sitios quedará:

Sitio alfa Sitio Beta Dato X Æ 1000

Última modificación Æ 10α

Dato X Æ 1000

Última modificación Æ 10α

Con el mecanismo definido anteriormente se basa en que el proceso Administrador de Datos “controla” por posibles conflictos, este comportamiento presenta otro cambio respecto al contenido de la sección 6.1.1.

Por último, el proceso Propagador posee una cola de mensajes donde se depositan las actualizaciones que debe propagar. De esta forma, la replicación se maneja de manera asincrónica sin afectar al resto de los procesos o subprocesos.

Nótese la diferencia existente entre esta implementación de Propagador respecto a la propuesta por el esquema de propagación Eager.

Esquemas propietario (Master Slave o Group)

Los esquemas propietario MasterSlave y Group definen hacia donde se debe disparar la actualización de un elemento de datos. Para la implementación de los procesos y subprocesos de la sección 6.1.1. esta elección no presenta una diferencia importante, basta solamente con indicar que tipo de política se debe seguir para que el proceso Administrador de Datos decida si puede o no actualizar un dato particular y los proceso que serán involucrados.

En caso de tratarse de un esquema Master Slave, debe realizar la actualización sobre la copia maestra, de esta forma, si la copia maestra reside en su sitio procederá como si se tratara del único elemento de datos (para problemas de exclusión mutua), o, en su defecto, se comunicará con el Administrador de Datos del sitio que contiene esa réplica maestra, utilizando los mecanismos descriptos anteriormente. El nodo conteniendo la copia primaria (maestra) será responsable, luego, de propagar los cambios sobre copias esclavas (nuevamente operando de manera similar a la presentada).

Si se tratara de un esquema Group, la diferencia de base sería que se debe garantizar la exclusión mutua, el mecanismo debe actualizar todas las réplicas simultáneamente, pero la situación ya está contemplada en la definición de los casos anteriores.