Control de Concurrencia

Es el proceso de gestionar una serie de operaciones simultáneas en la base de datos de modo que éstas no interfieran unas con otras.

Planificación en Serie Es aquella en la que las operaciones de cada

transacción se ejecutan consecutivamente sin que se entrelacen operaciones de otras transacciones, es decir, no hay interpolación, por lo que sólo hay una transacción activa al mismo tiempo, hasta que se confirme o cancele la transacción activa no se inicia la siguiente transacción.

Ejemplo: planificación en SerieT1 T2

Begin_Transaction read(X) write(X) read(Y) write(Y)Commit

Begin_Transaction read(X) write(X) read(Y) write(Y)Commit

Planificación no serie: Es aquella en la que las operaciones de un

conjunto de transacciones concurrentes están entrelazadas

T1 T2

Begin_Transaction read(X) X:=X-N

write(X) read(Y)

Y:= Y+N write(Y)Commit

Begin_Transaction read(X) X:=X+M

write(X)Commit

T1 T2

Begin_Transaction read(X) X:=X-N write(X)

read(Y) Y:= Y+N write(Y)Commit

Begin_Transaction read(X) X:=X+M write(X)Commit

Planificación A Planificación B

Si X= 90 e Y=90, y N=3 y M=2, Podemos observar que la planificación A obtiene un dato erróneo de X=92, esto se debido a que la T2 lee el valor de X antes de que la T1 escriba el nuevo valor de X, Sin embargo la planificación B si ofrece un resultado correcto.

Planificaciones Serializables: Se dice que una planificación S de n transacciones es serializable si es equivalente a alguna planificación en serie de las mismas transacciones. Es decir, son planificaciones no serie que permiten ejecutarse concurrentemente sin interferir entre sí, y producir los mismos resultados de una planificación en serie.

Pa: R1(x);R2(x);W1(x);R1(y);W2(x);W1(y)Pb: R1(x);W1(x);R2(x);W2(x);R1(y);W1(y)

Dos planificaciones son equivalentes por conflicto si el orden de cualquier par de operaciones en conflicto es el mismo orden en las dos planificaciones

Pc: R1(x); W1(x); R1(y);W1(y);R2(x);W2(x);

Ejemplo utilizando la Planificación b

T1 T2

Begin_Transaction read(X) X:=X-N write(X)

read(Y) Y:= Y+N write(Y)Commit

Begin_Transaction read(X) X:=X+M write(X)Commit

T1 T2

Begin_Transaction read(X) X:=X-N write(X) read(Y) Y:= Y+N write(Y)Commit Begin_Transacti

on read(X) X:=X+M write(X)Commit

Planificaciones EquivalentesPlanificación BPlanificación C

Pa: R1(x);R2(x);W1(x);R1(y);W2(x);W1(y)

Pd: R1(x); W1(x);R1(y);W1(y);R2(x);W2(x)

Pe: R2(x);W2(x); R1(x); W1(x);R1(y);W1(y);

Conclusión la planificación a no es serializable

Algoritmo para determinar la serialización por conflicto de una planificaciónSe analizan sólo las operaciones de lectura y

escritura de una planificación S y se construye un gráfico de precedencia.

Para cada transacción Ti, participante en la planificación S, se crea un nodo etiquetado como Ti

Para cada caso de S donde Tj ejecute una operación de Write(x) después de que Ti ejecute Read(x), crear un arco (Ti Tj)

Para cada caso de S donde Tj ejecute una operación de Read(x) después de que Ti ejecute Write(x), crear un arco (Ti Tj)

Para cada caso de S donde Tj ejecute una operación de Write(x) después de que Ti ejecute Write(x), crear un arco (Ti Tj)

La planificación S es serializable si, y sólo si, el gráfico de precedencia no tiene ciclos

Pa: R1(x);R2(x);W1(x);R1(y);W2(x);W1(y)

T1

T2

X

X

Pb: R1(x);W1(x);R2(x);W2(x);R1(y);W1(y)

T1

T2X

Control de ConcurrenciaCuando se modifica un registro desde una

transacción, éste se bloquea para modificaciones desde otra transacción; el bloqueo impide que se haga una segunda modificación sobre los mismos datos mientras todavía no se han aceptado o rechazado los primeros.

Hay dos metodologías de bloqueo: optimista y pesimista.

Los servidores que implementan bloqueos pesimistas asumen que es muy probable que dos usuarios accedan simultáneamente a los datos para modificarlos; entonces toman una postura preventiva y cuando un usuario empieza a editar un registro éste queda inmediatamente bloqueado para la edición desde cualquier otra terminal. Este modo de trabajo es muy común en los sistemas de bases de datos de escritorio.

Los servidores SQL asumen en cambio que no es tan

probable que se produzcan ediciones simultáneas a los mismos

registros; basándose en este supuesto, solamente bloquea un

registro cuando se ha realizado realmente una modificación en el

mismo –notificando a la base de datos mediante Post, por ejemplo.

Note que no hemos terminado todavía la transacción. Mientras

tanto, el mismo registro puede estar siendo modificado en la

memoria interna de varias terminales a la vez. La primera

terminal que guarde el registro (post) bloquea los cambios de las

demás. Cómo reaccionarán las aplicaciones que se encuentran con

el bloqueo, depende de la configuración de las correspondientes

transacciones como se demuestra a continuación.

El parámetro que se indica cómo reaccionará una transacción al encontrarse un registro bloqueado se denomina nivel de bloqueo, y se configura al momento de comenzar la transacción. Por ejemplo Firebird tiene las siguientes opciones:

 Modo en espera (WAIT): si hay un conflicto

con otra transacción (por ejemplo, las dos tratan de modificar el mismo registro y aceptar los cambios), el último proceso queda bloqueado hasta que se termina la primera transacción.

 Modo sin espera (NO WAIT): si hay un

conflicto con otra transacción, el proceso recibe un mensaje de error inmediatamente.

Bloqueo:Es un procedimiento utilizado para controlar el

acceso concurrente a los datos, un bloque puede denegar el acceso a otras transacciones con el fin de impedir que se produzcan resultados incorrectos. Los Bloqueos no importa del tipo que sean deben pedir un bloqueo compartidos (lectura) o exclusivos (escrituras).

Tipos de Bloqueos:Compartidos: Si una transacción tiene bloqueo compartido sobre un elemento de datos, puede leer el elemento, pero no actualizarlo.

Exclusivo: Si una transacción tiene bloqueo exclusivo sobre un elemento de datos, puede leer y actualizar el elemento

Los niveles de aislamiento de transacciones de Firebird son los siguientes:

read commited (lectura de lo aceptado): si estamos en una transacción con este nivel de aislación, podremos ver los cambios de los demás cuando ellos terminen su transacción con commit (nosotros tendremos que repetir la consulta, o sea cerrar y volver a abrir el conjunto de datos). No es necesario que terminemos nuestra transacción para ver las modificaciones.

snapshot (lectura repetible): se garantiza que el usuario que esté en una transacción de este tipo verá siempre los mismos datos, aunque otros usuarios hagan cambios y los acepten. No veremos los cambios hasta que cerremos nuestra transacción y comencemos una nueva. Este nivel de aislamiento es ideal para los reportes, ya que en un entorno multiusuario puede darse que cambien los datos entre el momento de la vista previa en pantalla y la impresión propiamente dicha.

snapshot table stability (lectura repetible forzada): igual que la anterior, pero además desde el momento que accedemos a una tabla ésta se bloquea para escritura. Este nivel es propio de Interbase, y no es muy usado porque impone una restricción muy severa a los otros usuarios, que sólo estarán habilitados para leer de todas las tablas que toquemos mientras estemos en la transacción.

 Hay un nivel más de aislamiento que es común en

los sistemas de bases de datos locales: el llamado dirty read o de ‘lectura sucia’. En este nivel se pueden ver los cambios de las demás transacciones. En otros sistemas (y en la BDE) se denomina Repeatable Read a este nivel de aislamiento.