Cuando se diseñan esquemas de control de concurrencia, es necesario que de- mostrar que las planificaciones que genera el esquema son secuenciables. Para lo- grarlo se debe entender primero la forma de determinar si, dada una planificación concreta P, es secuenciable.
A continuación, se presenta un método simple y eficiente de determinar la se- cuencialidad en cuanto a conflictos de una planificación. Considérese una planifica- ción P. Se construye un grafo dirigido, llamado grafo de precedencia para P. Este grafo consiste en un par G = (V, A), siendo V un conjunto de vértices y A un conjunto de arcos. El conjunto de vértices consiste en todas las transacciones que participan en la planificación. El conjunto de arcos consiste en todos los arcos Ti→ Tj para los cuales se dan una de las tres condiciones siguientes:
1. Ti ejecuta escribir(Q) antes de que Tj ejecute leer(Q). 2. Ti ejecuta leer(Q) antes de que Tj ejecute escribir(Q). 1. Ti ejecuta escribir(Q) antes de que Tj ejecute escribir(Q).
Si existe un arco Ti→ Tj en el grafo de precedencia, entonces en toda planifica- ción secuencial P' equivalente a P, Ti debe aparecer antes de Tj.
Por ejemplo, en la figura 5.6 (a) se muestra el grafo de precedencia de la planifi- cación 1. Sólo contiene el arco T1→ T2, puesto que todas las instrucciones de T1 se ejecutan antes de que lo haga la primera de T2. Análogamente, la figura 5.6 (b) que muestra el grafo de precedencia de la planificación 2 con el único arco T2→ T1, ya que todas las instrucciones de T2 se ejecutan antes de que lo haga la primera de T1.
Figura 5.6. Grafo de precedencia para (a) la planificación 1 y (b) la planificación 2.
El grafo de precedencia de la planificación 4 se representa en la figura 5.7. Con- tiene el arco T1→ T2 debido a que T1 ejecuta leer(A) antes de que T2 ejecute escri- bir(A). También contiene el arco T2→ T1 debido a que T2 ejecuta leer(B) antes de que T1 ejecute escribir(B).
Si el grafo de precedencia de P tiene un ciclo, entonces la planificación P no es secuenciable en cuanto a conflictos. Si el grafo no contiene ciclos, entonces la plani- ficación P es secuenciable en cuanto a conflictos.
Figura 5.7. Grafo de precedencia para la planificación 4.
El orden de secuencialidad, se puede obtener a través de la ordenación topológi- ca, la cual determina un orden lineal que consiste en el orden parcial del grafo de precedencia. En general, se pueden obtener muchos órdenes lineales posibles a tra- vés de la ordenación topológica. Por ejemplo, el grafo de la figura 5.8 (a) tiene dos órdenes lineales aceptables, como se observa en las figuras 5.8 (b) y 5.8 (c).
(a)
(b) (c)
Figura 5.8. Muestra la ordenación topológica.
Así, para probar la secuencialidad en cuanto a conflictos es necesario construir el grafo de precedencia e invocar a un algoritmo de detección de ciclos. Los algoritmos de detección de ciclos, tales como los que se basan en la búsqueda primero en pro- fundidad, requieren del orden de n operaciones, siendo n el número de vértices del
grafo (es decir, el número de transacciones). De este modo se consigue un esquema práctico para determinar la secuencialidad en cuanto a conflictos.
Volviendo a los ejemplos anteriores, obsérvese, que los grafos de precedencia para las planificaciones 1 y 2 (figura 5.6) no contienen ciclos. El grafo de precedencia para la planificación 4 (figura 5.7), sin embargo, contiene ciclos, lo que indica que esta planificación no es secuenciable en cuanto a conflictos.
La comprobación de la secuencialidad en cuanto a vistas es más complicada. De hecho, se ha demostrado que el problema de determinar la secuencialidad en cuanto a vistas es NP completo. Por tanto, seguramente no exista ningún algoritmo eficiente para comprobar la secuencialidad en cuanto a vistas.
En conclusión, una transacción es una unidad de ejecución de un programa que accede y posiblemente actualiza varios elementos de datos. Es fundamental comprender el concepto de transacción para entender e implementar las actualiza- ciones de los datos en una base de datos, de manera que las ejecuciones concurren- tes y los fallos de varios tipos no den como resultado que la base de datos se vuelva inconsistente (Silberschatz, Korth, Sudarshan 2006).
Puesto que una transacción es una unidad que conserva la consistencia, una eje- cución secuencial de transacciones garantiza que se conserve dicha consistencia.
El componente de gestión de control de concurrencia de la base de datos es el responsable de manejar los esquemas de control de concurrencia.
CAPÍTULO VI
6. METODOLOGÍA PARA IMPLEMENTAR SIMULADOR PROTOTIPO DE APLICACIÓN UTILIZANDO ALGORITMOS GENÉTICOS PARA OPTIMIZAR PROCESO TRANSACCIÓN EN LA WEB
6.1 INTRODUCCIÓN
Se ha tomado como base el capítulo V y conocimientos sobre los Algoritmos Ge- néticos, para implementar un simulador prototipo de aplicación utilizando algoritmos genéticos para optimizar el proceso de transacción en la web.
El objetivo es implementar un simulador de transacciones orientando a la toma de decisiones del administrador de transacciones con la aplicación de algoritmos genéti- cos. Se usará los algoritmos genéticos para determinar que transacción se debe to- mar para asignarlo en la cola de procesos.
Se asumen, ciertas restricciones que el simulador tomará como dadas. Por ejem- plo, cada transacción tiene un número constante de recursos que solicitan. Cada re- curso tiene una cola que administra y solo se pueden hacer 2 tipos de requerimiento: leer y escribir.
La estructura de un cromosoma consta de un grupo de alelos y cada uno corres- ponde con un recurso solicitado. El administrador de transacciones tomará el reque- rimiento por el recurso para ponerlo en cola, el que tenga un máximo de cromosoma igual a 1, es decir, cuando encuentre entre el grupo de transacciones la transacción que tenga sus alelos en 1. Se tomará como cromosoma una cadena binaria que será convertida a números enteros.
Se ha realizado un análisis de los modelos de transacciones que operan actual- mente y se ha extraído tales mecanismos para llevarlo a un proceso de toma de de- cisiones en función de los algoritmos genéticos.
El presente documento compila todo el análisis realizado tal como los anteceden- tes, las restricciones que se llevan al modelo, los requerimientos y los diagramas del modelo.