Control de Concurrencia Es el proceso de gestionar una serie de operaciones simultneas en la base de datos de modo que stas no interfieran unas

con otras. Planificacin en Serie Es aquella en la que las operaciones de cada transaccin se ejecutan consecutivamente sin que se entrelacen operaciones de otras transacciones, es decir, no hay interpolacin, por lo que slo hay una transaccin activa al mismo tiempo, hasta que se confirme o cancele la transaccin activa no se inicia la siguiente transaccin.

Ejemplo: planificacin en Serie

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

 Planificacin no serie:

Es aquella en la que las operaciones de un conjunto de transacciones concurrentes estn entrelazadas

Planificacin A
T1 Begin_Transaction read(X) X:=X-N T2

Planificacin B
T1 Begin_Transaction read(X) X:=X-N write(X) Begin_Transaction read(X) X:=X+M write(X) Commit read(Y) Y:= Y+N write(Y) Commit T2

Begin_Transaction read(X) X:=X+M

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

 Si X= 90 e Y=90, y N=3 y M=2, Podemos observar

que la planificacin A obtiene un dato errneo 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 planificacin B si ofrece un resultado correcto.
Planificaciones Serializables: Se dice que una planificacin S de n transacciones es serializable si es equivalente a alguna planificacin 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 planificacin 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
Ejemplo utilizando la Planificacin b

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

Planificaciones Equivalentes
Planificacin C
T1 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 T2

Planificacin B
T1 Begin_Transaction read(X) X:=X-N write(X) Begin_Transaction read(X) X:=X+M write(X) Commit T2

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

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);

Conclusin la planificacin a no es serializable

Algoritmo para determinar la serializacin por conflicto de una planificacin

Se analizan slo las operaciones de lectura y escritura

de una planificacin S y se construye un grfico de precedencia. Para cada transaccin Ti, participante en la planificacin S, se crea un nodo etiquetado como Ti Para cada caso de S donde Tj ejecute una operacin de Write(x) despus de que Ti ejecute Read(x), crear un arco (Ti Tj) Para cada caso de S donde Tj ejecute una operacin de Read(x) despus de que Ti ejecute Write(x), crear un arco (Ti Tj)

 Para cada caso de S donde Tj ejecute una operacin de

Write(x) despus de que Ti ejecute Write(x), crear un arco (Ti Tj) La planificacin S es serializable si, y slo si, el grfico de precedencia no tiene ciclos
Pa: R1(x);R2(x);W1(x);R1(y);W2(x);W1(y)
X T1 X T2 Pb: R1(x);W1(x);R2(x);W2(x);R1(y);W1(y)

T1 X

T2

Control de Concurrencia
Cuando se modifica un registro desde una transaccin, ste se bloquea para modificaciones desde otra transaccin; el bloqueo impide que se haga una segunda modificacin sobre los mismos datos mientras todava no se han aceptado o rechazado los primeros. Hay dos metodologas de bloqueo: optimista y pesimista. Los servidores que implementan bloqueos pesimistas asumen que es muy probable que dos usuarios accedan simultneamente 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 edicin desde cualquier otra terminal. Este modo de trabajo es muy comn en los sistemas de bases de datos de escritorio.

Los servidores SQL asumen en cambio que no es tan probable que se produzcan ediciones simultneas a los mismos registros; basndose en este supuesto, solamente bloquea un registro cuando se ha realizado realmente una modificacin en el mismo notificando a la base de datos mediante Post, por ejemplo. Note que no hemos terminado todava la transaccin. 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 dems. Cmo reaccionarn las aplicaciones

que se encuentran con el bloqueo, depende de la configuracin de las

correspondientes transacciones como se demuestra a continuacin.

El parmetro que se indica cmo reaccionar una transaccin al encontrarse un registro bloqueado se denomina nivel de bloqueo, y se configura al momento de comenzar la transaccin. Por ejemplo Firebird tiene las siguientes opciones: Modo en espera (WAIT): si hay un conflicto con otra transaccin (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 transaccin. Modo sin espera (NO WAIT): si hay un conflicto con otra transaccin, 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 transaccin tiene bloqueo compartido sobre un elemento de datos, puede leer el elemento, pero no actualizarlo.

Exclusivo: Si una transaccin 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 transaccin con este nivel de aislacin, podremos ver los cambios de los dems cuando ellos terminen su transaccin 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 transaccin para ver las modificaciones. snapshot (lectura repetible): se garantiza que el usuario que est en una transaccin de este tipo ver siempre los mismos datos, aunque otros usuarios hagan cambios y los acepten. No veremos los cambios hasta que cerremos nuestra transaccin 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 impresin propiamente dicha.

snapshot table stability (lectura repetible forzada): igual que la anterior, pero adems 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 restriccin muy severa a los otros usuarios, que slo estarn habilitados para leer de todas las tablas que toquemos mientras estemos en la transaccin. Hay un nivel ms de aislamiento que es comn 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 dems transacciones. En otros sistemas (y en la BDE) se denomina Repeatable Read a este nivel de aislamiento.