Clasificación de Algoritmos

Los ACC distribuidos existentes se agrupan en 2 clases generales para

sincronización [TOZS99]: pesimista (pessimistic), el cual sincroniza la ejecución

concurrente de las solicitudes de usuarios antes que la transacción inicie, y

optimista (optimistic), que ejecuta las solicitudes y luego realiza una validación para asegurar que la ejecución no ha comprometido la consistencia de la Base de Datos. Para nuestro interés, el trabajo se centrará en un ACC pesimista dado que es el enfoque actualmente más utilizado y documentado. La clasificación mencionada se ilustra en la Figura 3.1.

Los dos enfoques fundamentales que pueden ser usadas tanto en la clase

pesimista como en la clase optimista son: bloqueo (locking), que es basado en la

exclusión mutua de acceso a datos, y marcas de tiempo (timestamping), donde

las transacciones son ejecutadas en algún orden por identificadores. Existen

variaciones de estos esquemas conocidos como algoritmos híbridos (hybrid) que

intentan combinar los dos mecanismos básicos.

Concurrency Control Algorithms Pessimistic Optimistic Centralized Primary Copy Distributed Locking Timestamp Ordering Locking Timestamp Ordering Hybrid Basic Multi Version Conservative

3.2.1 Algoritmos basados en bloqueo

La idea principal de este tipo de algoritmos es asegurar que un dato que es compartido por operaciones conflictivas sea accedido por una operación a la vez.

Esto es cumplido asociando un “bloqueo” a cada unidad de bloqueo (una unidad

de bloqueo es una porción de la DB que contiene el dato que interesa bloquear). En los algoritmos basados en bloqueo:

x Las transacciones indican sus intenciones al solicitar bloqueo al Manejador

de Bloqueo (Lock Manager ó LM).

x Los bloqueos son read lock (rl) o write lock (wl, también llamado exclusive

lock).

x Existen conflictos entre read locks y write locks (porque las operaciones de

lectura y escritura son incompatibles).

El enfoque del bloqueo (en un entorno distribuido) puede ser de tipo

centralized, primary copy ó distributed [TOZS99].

En el bloqueo de tipo centralized (centralizado) se le delega la

responsabilidad solamente a un sitio (sitio primario) donde las tablas de bloqueo para la DB entera son almacenadas, y el cual es responsable de conceder bloqueos a las transacciones. Los manejadores de transacciones de los otros sitios se comunican con él en vez de hacerlo con sus propios manejadores de bloqueo. Este enfoque es también conocido como el algoritmo 2PL de sitio primario.

En el bloqueo de tipo primary copy (copia primaria) una de las copias de

cada unidad de bloqueo (del dato que se desea bloquear) es designada como copia primaria, y es esta copia que debe ser bloqueada para el propósito de acceder esta unidad particular. Este tipo de bloqueo es una extensión del

centralized. Aunque demanda un directorio sofisticado en cada sitio, reduce la carga del sitio central sin causar una larga medida de comunicación entre los manejadores de transacciones y manejadores de bloqueo.

En el bloqueo distributed (distribuido), el manejador de bloqueo responsable

es compartido por todos los sitios de una red. En este caso, la ejecución de una transacción envuelve la participación y coordinación de planificadores (schedulers) en más de un sitio. Cada planificador local es responsable de las unidades de bloqueo locales en ese sitio. Este tipo de bloqueo depende de la disponibilidad de los manejadores de cada sitio.

3.2.2 Algoritmos basados en ordenamiento por marcas de tiempo

A diferencia de los algoritmos de bloqueo, los algoritmos basados en ordenamiento por marcas de tiempo (T/O) envuelven la organización del orden de ejecución en transacciones, por lo que mantienen mutua consistencia. Este ordenamiento es mantenido al asignar marcas de tiempo (timestamps) tanto a las transacciones como a los datos que son almacenados en la DB. Una marca de tiempo es un simple identificador que sirve para reconocer cada transacción y para

permitir el ordenamiento. Estos algoritmos pueden ser de tipo basic, multiversion,

o conservative [TOZS99].

El proceso inicial del ordenamiento T/O es:

A una transacción Ti se le asigna una marca única de tiempo ts(Ti).

El administrador de transacciones agrega la marca a todas las operaciones ocupadas por la transacción.

A cada dato se le asigna una marca de escritura (wts) y una marca de lectura (rts).

x rst(x) = la marca más grande de las lecturas sobre x x wst(x) = la marca más grande de las escrituras sobre x

Las operaciones conflictivas son resueltas por orden de marcas (timestamp order). De acuerdo a [TOZS99] la regla T/O se especifica formalmente como sigue:

“Dadas 2 operaciones conflictivas Oij y Okl, pertenecientes a las transacciones Ti

y Tk respectivamente, Oij es ejecutada antes de Okl si y solo si ts(Ti) < ts(Tk)”. En este caso se dice que Ti es la transacción más antigua y Tk es la transacción más reciente.

En un algoritmo T/O basic (básico), una transacción que contiene una

operación que es rechazada es reiniciada por el administrador de transacciones con una nueva marca de tiempo. Esto asegura que la transacción tenga una oportunidad para ejecutarse en su próximo intento. Un ejemplo de T/O básico es el siguiente: For Ri(x) If ts(Ti) < wts(x) Then rechaza Ri(x) Else Acepta Ri(x) rts(x) <--- ts(Ti) For Wi(x)

If ts(Ti) < rts(x) and ts(Ti) < wts(x)

Then

rechaza Wi(x)

Else

acepta Wi(x) wts(x) <--- ts(Ti)

En el primer caso (para lectura de x en la transacción i) se tiene que si al comparar con la estampa de tiempo de Ti, la marca de escritura sobre x es más reciente, se rechaza la lectura. De lo contrario se acepta y por consiguiente, se le asigna como marca de lectura la estampa de tiempo de Ti.

En el caso de escritura (para x en Ti), se tiene que si al comparar con la estampa de tiempo de Ti, tanto la marca de escritura como la de lectura sobre x son más recientes, se rechaza la escritura. De lo contrario se acepta y se asigna como marca de escritura la estampa de tiempo de Ti.

Las versiones del algoritmo T/O se utilizan dependiendo de la carga o

rendimiento esperado. Por ejemplo el tipo conservative se utiliza cuando se desea

reducir el número de reinicios y aumentar el rendimiento, el tipo multiversion se

utiliza cuando se desea tener soporte para versiones de objetos de Bases de Datos (es decir no se modifica la Base de Datos sino se crea una nueva versión de datos).