Control de Concurrencia

UNIVERSIDAD DE EL SALVADOR
FACULTAD MULTIDISCIPLINARIA PARACENTRAL

DEPARTAMENTO DE INFORMATICA

BASES DE DATOS
CONTROL DE CONCURRENCIA

CATEDRATICO:
ING. HERBERT ORLANDO MONGE BARRIOS

ALUMNAS:
MARTA ELIDA, FLORES GOMEZ
VANESSA ILIANA, URRUTIA AREVALO

MARTES, 14 DE JUNIO DEL 2011

14 de jun.
2
INTRODUCCION

El control de transacciones concurrentes en una base de datos brinda un eficiente
desempeo del Sistema de Base de Datos, puesto que permite controlar la
ejecucin de transacciones que operan en paralelo, teniendo acceso a informacin
compartida y, por lo tanto, interactuando potencialmente unas con otras.
En la mayora de los sistemas operativos actuales, las diferentes tareas o hilos se
ejecutan de forma intercalada (incluso en el caso de mquinas con varios
procesadores). Es decir, el sistema operativo decide por su cuenta cuando
suspender una de las tareas y darle un poco de tiempo de ejecucin a otra. Si hay
tareas simultneas o concurrentes sobre la misma base de datos, esta
intercalacin puede resultar en que las lecturas y escrituras de las diferentes
tareas o aplicaciones en el medio fsico se realicen en cualquier orden y
secuencia.
El acceso simultneo descrito puede dar como resultados informacin
inconsistente o simplemente incorrecta, dependiendo de la mala o buena suerte
que tengamos en la intercalacin de las lecturas y escrituras simultneas. Esta
problemtica ha llevado a disear e implementar diferentes estrategias de control
de concurrencia


14 de jun.
3

La concurrencia en las bases de datos es de suprema importancia en los sistemas
informacin, ya que evita errores en el momento de ejecutar las diferentes
transacciones.
En si la concurrencia es la propiedad de los sistemas que permiten que mltiples
procesos sean ejecutados al mismo tiempo y que potencialmente puedan
interactuar entre s.
Como se ha observado anteriormente la concurrencia est ligada al trmino
transaccin, as que se dice que una transaccin es:
'Es una unidad de programa que tiene acceso y posiblemente actualiza
varios elementos de datos"
Es decir:
Cada transaccin accede a informacin compartida sin interferir con otras
acciones y si una transaccin termina normalmente, todos sus efectos son
permanentes en caso contrario no tienen efecto alguno.
Los sistemas que tratan el problema de control de concurrencia permiten que sus
usuarios asuman que cada una de sus aplicaciones sea ejecutada atmicamente,
como si no existieran otras aplicaciones ejecutndose concurrentemente.
Un algoritmo de control de concurrencia asegura que las transacciones se
ejecuten atmicamente controlando la intercalacin de transacciones
concurrentes, para dar la ilusin de que las transacciones se ejecutan seriamente,
una despus de la otra, sin ninguna intercalacin. Las ejecuciones intercaladas
cuyos efectos son los mismos que las ejecuciones seriales son denominadas
serializables y son correctos ya que soportan la ilusin de la atomicidad de las
transacciones.
Cada transaccin accede a informacin compartida sin interferir con otras
transacciones, y si una transaccin termina normalmente, todos sus efectos son
permanentes, en caso contrario no tiene afecto alguno.
PROPIEDADES DE LA TRANSACCION
x ATOMICIDAD:
Se refiere al hecho de que una transaccin se trata como una unidad de
operacin.

14 de jun.
4
Por lo tanto, o todas las acciones de la transaccin se realizan o ninguna de
ellas se lleva a cabo. La atomicidad requiere que si una transaccin se
interrumpe por una falla, sus resultados parciales sean anulados.
x CONSISTENCIA:
La consistencia de una transaccin es solamente su correctitud. En otras
palabras, una transaccin e un programa correcto que lleva a la base de
datos de un estado consistente a otro con la misma caracterstica. Debido a
esto las transacciones no violan las restricciones de integridad de una base
de datos.
x ASISLAMIENTO:
Una transaccin en ejecucin no puede revelar sus resultados a otras
transacciones concurrentes antes de finalizar.
Ms aun, si varias transacciones se ejecutan concurrentemente, los
resultados deben de ser los mismos que si ellas se hubieran ejecutado de
manera secuencial.
x DURABILIDAD O PERMANENCIA
Es la propiedad de las transacciones que asegura que una vez que una
transaccin finaliza exitosamente, su resultado es permanente y no pueden
ser borrados de la base de datos por una falla posterior.

Por lo tanto, los sistemas manejadores de bases de datos aseguran que los
resultados de una transaccin sobrevivirn a fallas del sistema. Esta propiedad
motiva el aspecto de recuperacin de bases de datos el cual trata sobre cmo
recuperar la base a un estado consistente donde todas las acciones que han
finalizado con xito queden reflejadas en la base.

TRANSACCION
El procesamiento de transacciones es una de las tareas ms importantes dentro
de un sistema de base de datos, pero a la vez, es una de las ms difciles de
manejar debido a diversos aspectos tales, como:
x Confiabilidad: puesto que los sistemas de bases en lnea no pueden fallar.
x Disponibilidad: debido a que los sistemas de bases de datos en lnea deben
de estar actualizados correctamente todo el tiempo.
x Tiempos de respuesta: en sistemas de este tipo, el tiempo de respuesta de
las transacciones no debe de ser mayor a 12 segundos.

14 de jun.
5
x Throughput: los sistemas de bases de datos en lnea requieren procesar
miles de transacciones por segundo.
x Atomicidad: en el procesamiento de transacciones no se aceptan resultados
parciales.
x Permanencia: no se permite la eliminacin en la base de datos de los
efectos de una transaccin que ha culminado con xito.
Una base de datos est en un estado consistente si obedece todas las
restricciones de integridad (significa que cuando un registro en una tabla haga
referencia a un registro en otra tabla, el registro correspondientes debe existir)
definidas sobre ella.
Los cambios de estado ocurren debido a actualizaciones, inserciones y
supresiones de informacin. Por supuesto, se quiere asegurar que la base de
datos nunca entre en un estado de inconsistencia.
Sin embargo, durante la ejecucin de una transaccin, la base de datos puede
estar temporalmente en un estado inconsistente. El punto importante aqu es
asegurar que la base de datos regresa a un estado consistente al fin de la
ejecucin de una transaccin.
A continuacin se mostrar cual es el comportamiento que sigue una transaccin:

Al iniciar una transaccin en la base de datos, esta se encuentra en un estado
consistente debido a que aun se garantiza la veracidad de los datos dentro de la
base de datos por que cumple con todas las reglas de validacin de la aplicacin.

14 de jun.
6
Durante la ejecucin de la transaccin se dice que est en un estado inconsistente
debido a que como la transaccin aun no termina, no se sabe cul podra ser el
estado temporal de los datos.
Y al finalizar la transaccin la base de datos vuelve a su estado de consistencia ya
que ha cumplido con las normas generales que estn dentro del mbito de la
aplicacin.
EJEMPLO:

Como se observa en el grafico se tiene una transaccin en la que se debe de
ejecutar una operacin, al iniciar la transaccin x posee un valor determinado
donde x=40 y al finalizar posee otro, x=30. El estado de inconsistencia se da en el
momento que se est ejecutando la resta (x-10) entre los valores ya establecidos.
En esencia, lo que se persigue con el procesamiento de transacciones es, por una
parte obtener una transparencia adecuada de las acciones concurrentes a una
base de datos y por otra parte manejar adecuadamente las fallas que se puedan
presentar en una base de datos.
Un SGBD se dice transaccional si es capaz de mantener la integridad e los datos,
haciendo que estas transacciones no puedan finalizar en un estado intermedio.
Cuando por alguna causa el sistema debe de cancelar la transaccin, empieza a
deshacer las rdenes ejecutadas hasta dejar la base en su estado inicial (llamado
punto de integridad) como si la orden de la transaccin nunca hubiese sido
realizada.
ACCIONES QUE DEBEN DE CONSTITUIR UNA TRANSACCION
x BEGIN: especifica que va a empezar una transaccin.

14 de jun.
7
x COMMIT: le indica al motor que puede considerar la transaccin
completada con xito.
x ROLLBACK: indica que se ha alcanzo un fallo y que debe de restablecer la
base al punto de integridad.

REGISTRO DE TRANSACCIONES
Un DBMS utiliza un registro de transacciones para dar seguimiento a todas las
transacciones que actualizan la base de datos. La informacin guardada en este
registro es utilizada por el DBMS para un requerimiento de recuperacin activo por
una sentencia ROLLBACK.

TRANSACCIONES
Mientras que el DBMS ejecuta transacciones que modifican la base de datos,
tambin actualiza automticamente el registro de transacciones. El registro de
transacciones guarda:
x Un registro de inicio de transaccin
x Por cada componente de transaccin (sentencia SQL) guarda:
El tipo de operacin que este realizando (actualizando, eliminacin,
insercin).
Los nombres de los objetos afectados por la transaccin (el nombre
de la tabla).
Los valores "antes y "despus de los campos que se estn
actualizando.
Sealizadores de los ingresos de registro de transaccin previo y
siguiente para la misma transaccin.
Un registro de inicio de la transaccin.
x La finalizacin (COMMIT) de la transaccin.
Forma algortmica que suelen tener las transacciones es la siguiente:

14 de jun.
8

Notas:
9 Por default toda transaccin tiene autocommit = 1
9 El rollback generalmente se usa en el catch de los programas, aunque
puede ir en cualquier parte.
9 Una transaccin que no llega al commit automticamente hace el rollback
9 SET AUTOCOMMIT = {0 | 1}
Si el modo de autocommit est en apagado SET AUTOCOMMIT = 0, entonces se
asume que la misma transaccin continua hasta que se realice un COMMIT o un
ROLLBACK. Donde un commit actualizar los datos a almacenar. Por default el
modo de autocommit est encendido, de manera que cada operacin es
considerada una transaccin y todo cambio se va reflejando automticamente en
la base de datos.

NIVELES DE AISLAMIENTO
Las transacciones especifican un nivel de aislamiento que define el grado en que
se deben aislar una transaccin de las modificaciones de recursos o datos
realizadas por otras transacciones. Los niveles de aislamiento se describen en
cuanto a los efectos secundarios de la simultaneidad que se permiten como las
lecturas no confirmadas o las lecturas ficticias.
Los niveles de aislamiento de transacciones controlan los siguientes aspectos:
x Si se realizan bloqueos cuando se leen los datos y que tipos de bloqueos
se solicitan.

14 de jun.
9
x La duracin de los bloqueos de lectura.
x Si una operacin de lectura que hace referencia a filas modificadas por otra
transaccin.
x Se bloquea hasta que se libera el bloqueo exclusivo de la fila.
x Recupera la versin confirmada de la fila que exista en el
momento en el que empez la instruccin o la transaccin.
x Lee la modificacin de los datos no confirmados.

x READ COMMITED(Lecturas confirmadas)
Adquiere un bloqueo compartido mientras incluye una fila en un cursor pero
libera el bloqueo inmediatamente despus de leer la fila.
x READ UNCOMMITED(Lecturas no confirmadas)
No solicita bloqueos mientras incluye una fila en un curso y no respeta
ningn bloqueo exclusivo. Se pueden llenar los cursores con los valores
que ya se han actualizado pero que aun no se han confirmado.
x REPEATABLE READ(Lectura repetible) O SERIALIZABLE
Solicita un bloqueo compartido en cada fila a medida que la incluyen en el
cursor, como en READ COMMITED, pero si el cursor se abre dentro de una
transaccin, se mantienen los bloqueos compartidos hasta el final de la
transaccin en lugar de liberarse tras leer la fila.
x SN APSHOP(Instantnea)
No solicita bloqueos mientras incluye una fila en un cursor y no respeta
ningn bloqueo exclusivo. El cursor se llena con los valores a partir del
momento en que se inicia por primera vez la transaccin. Se siguen
solicitando bloqueos de desplazamiento, con independencia del uso de
aislamiento de instantnea.

SQL estndar define 4 niveles de aislamiento en trmino de 3 fenmenos que
deben ser prevenidos entre transaccin concurrentes. Estos son:
DIRTY READ: Una transaccin lee datos escritos por una transaccin
concurrente que no ha hecho "commit.
NONREPEATABLE READ: Una transaccin re-lee datos que ley
previamente y encuentra que han sido modificados por otra transaccin
(que hizo commit)
PHANTOM READ: Una transaccin re-ejecuta un query regresando un
conjunto de tuplas que satisfacen una condicin de bsqueda y encuentra

14 de jun.
10
que el resultado ha cambiado debido a otra transaccin que hizo "commit
recientemente.
NIVELES DE AISLAMIENTO EN SQL
Nivel se aislamiento DirtyRead NonrepeatableRead PhantomRead
Readuncommitted Posible Posible Posible
Readcommitted No posible Posible Posible
Repeatableread No posible No posible Posible
Serializable No posible No posible No posible
*PostgreSQL ofrece ReadCommitted (default) y Serializable, la mayora de los
dbms ofrecen los 4 niveles

CORRECTITUD EN LA EJECUCIN CONCURRENTE DE TRANSACCIONES
Dadas las siguientes transacciones que se ejecutan concurrentemente:
Donde R=4
TRANSACCION A TIEMPO TRANSACCION B
-
-
-
FIND R t1 -
copy RF into ATEMP -
- t2 FIND R
- copy R.F into BTEMP .
- -
- -
UPD R t3 -
REPLACE RF -
by ATEMP + 1 -
- -
- t4 UPD R
- replace RF
- by 2 * BTEMP

La transaccin A se propone sumar 1 al campo F del registro R
La transaccin B se propone multiplicar por 2 ese mismo campo.
Si el valor inicial de F es 4 se tiene que:
Si la transaccin A se ejecuta antes que la transaccin B se tiene que F = 10,
ya que

14 de jun.
11
Transaccin A: 4 + 1 = 5
Transaccin B: 5 * 2 = 10
Si la transaccin B se ejecuta antes que la transaccin A se tiene que F = 9,
ya que
Transaccin B: 4 * 2 = 8
Transaccin A: 8 + l = 9
Cualquiera de los dos valores anteriores es considerado un resultado final
correcto ya que se cumple que "Si se da como entrada un estado correcto de
la base de datos, una transaccin individualmente correcta producir un
estado correcto de la base de datos como salida si es ejecutada en forma
aislada". A partir de esto se puede definir el concepto de correctitud en un
ambiente de ejecucin concurrente de transacciones.
Correctitud: Una ejecucin concurrente de un conjunto de transacciones (t1,
t2.tn) es correcta si y slo si existe una secuencia de dichas transacciones que
ejecutadas serialmente daran los mismos resultados.
Se dice entonces que si el concepto de correctitud se cumple el conjunto de
transacciones es serializable.
Para examinar la correctitud de la ejecucin concurrente de un conjunto de
transacciones hay que definir la precedencia existente entre las mismas.
Entonces se tiene que una transaccin A precede a una transaccin B si la
transaccin B ve un dato que la transaccin A modific o si la transaccin A ve un
dato que la transaccin B modificar.
En el ejemplo anterior se tiene que la ejecucin concurrente de A y B no es
correcta ya que A precede a B porque A ve un dato que B modificar y al mismo
tiempo B precede a A ya que B ve un dato que A modificar. Entonces no se
puede establecer una serializacin posible entre ambas transacciones. Si ambas
transacciones se ejecutan concurrentemente se obtiene que el valor de F es 8, ya
que:
Transaccin A: 4
+ 1 = 5
Transaccin B: 4
* 2 = 8
Este resultado no se corresponde con ninguno de los obtenidos por la ejecucin
serial de ambas transacciones y se dice que en este caso se presenta el

14 de jun.
12
problema de la actualizacin perdida, ya que la actualizacin que hace A se
pierde porque B la sobrescribe.
Es claro, entonces, que en un ambiente multiusuario es necesario algn
mecanismo de control de concurrencia con el fin de evitar estos problemas y
otros. El problema esencial aqu es que ambas transacciones A y B actualizan RF
sobre la base del valor inicial del campo y ninguna ve la salida de la otra
transaccin. Para prevenir esta situacin hay tres cosas bsicas que puede hacer
un mecanismo de control de concurrencia:
a) a) Puede impedir el FIND de B en el tiempo t2 en base al hecho de que la
transaccin A ya ha direccionado al registro R y puede ser que vaya a
actualizarlo posteriormente.
b) Puede impedir la actualizacin de A en el tiempo t3 en base al hecho de
que B ya ha direccionado al registro R y B ya ha visto el valor de R antes
de la actualizacin.
c) Puede impedir la actualizacin de B en el tiempo t4 en base al hecho de
que A ya ha actualizado a R y entonces la actualizacin de B va a estar
basada en un valor obsoleto de R.

ALGORITMOS BASADOS EN CANDADOS
En los algoritmos basados en candados, las transacciones indican sus intenciones
solicitando candados al despachador (llamado el administrador de candados). Los
candados son de lectura (rl), tambin llamados compartidos, o de escritura (wl),
tambin llamados exclusivos. Como se aprecia en la tabla siguiente, los candados
de lectura presentan conflictos con los candados de escritura, dado que las
operaciones de lectura y escritura son incompatibles.

En sistemas basados en candados, el despachador es un administrador de
candados (LM). El administrador de transacciones le pasa al administrador de
candados la operacin sobre la base de datos (lectura o escritura) e informacin
asociada, como por ejemplo el elemento de datos que es accesado y el
identificador de la transaccin que est enviando la operacin a la base de datos.
El administrador de candados verifica si el elemento de datos que se quiere
accesar ya ha sido bloqueado por un candado. Si candado solicitado es

14 de jun.
13
incompatible con el candado con que el dato est bloqueado, entonces, la
transaccin solicitante es retrasada.
De otra forma, el candado se define sobre el dato en el modo deseado y la
operacin a la base de datos es transferida al procesador de datos. El
administrador de transacciones es informado luego sobre el resultado de la
operacin. La terminacin de una transaccin libera todos los candados y se
puede iniciar otra transaccin que estaba esperando el acceso al mismo dato.

BLOQUEO O SEGURO.
Se puede definir bloqueo (tambin llamado seguro o candado) como "una variable
asociada a cada elemento de datos, que describe el estado de dicho elemento
respecto a las posibles operaciones (recuperacin o actualizacin) que se pueden
realizar sobre ellos en cada momento".
Las transacciones pueden llevar a cabo bloqueos, por ejemplo, sobre los registros
que vayan a utilizar, impidiendo a otros usuarios la recuperacin o actualizacin de
los elementos bloqueados, pudindose as evitar inconsistencias en el acceso
concurrente.
Los bloqueos pueden ser de varios tipos:
x Bloqueos exclusivos (o de escritura): Cuando una transaccin mantiene
un bloqueo de este tipo sobre un objeto, ninguna otra transaccin puede
acceder a l, ni adquirir ningn tipo de bloqueo sobre ese objeto, hasta que
sea liberado por la transaccin que lo haba retenido. Este tipo de bloqueos
se utiliza cuando una transaccin quiere actualizar algn objeto. Los
bloqueos exclusivos evitan que transacciones simultneas tengan acceso a
un recurso. Al utilizar un bloqueo exclusivo, el resto de las transacciones no
pueden modificar los datos; las operaciones de lectura solo se pueden
realizar si se utiliza la sugerencia NOLOCK o el nivel de aislamiento de
lectura no confirmada.
Las instrucciones para modificar datos, como INSERT, UPDATE Y DELETE
combinan las operaciones de modificacin con las de lectura. En primer
lugar, la instruccin lleva a cabo operaciones de lectura para adquirir los
datos antes de proceder a ejecutar las operaciones de modificacin de
datos suelen solicitar bloqueos compartidos y exclusivos. Por ejemplo, una
instruccin UPDATE puede modificar las filas de una tabla a partir de una
combinacin con otra tabla. En este caso la instruccin UPDATE solicita

14 de jun.
14
bloqueos compartidos para las filas ledas en la tabla de combinacin,
adems de bloqueos exclusivos para las filas actualizadas.
Para aplicar el candado exclusivo se puede hacer mediante el uso
cualquiera de las siguientes sentencias:
SELECT... FROM... FOR UPDATE
Aplica bloqueos exclusivos en todos los registros ndices encontrados.
INSERT INTO... VALUES (...)
Aplica un bloqueo exclusivo en la tupla insertada.
UPDATE... SET... WHERE...
Aplica un bloqueo exclusivo en cada registro encontrado.
DELETE FROM... WHERE...
Aplica un bloqueo exclusivo en cada registro encontrado.

x Bloqueos compartidos (o de lectura): Cuando una transaccin tiene
sobre un objeto un bloqueo de tipo compartido, permite que otras
transacciones retengan tambin ese mismo objeto en bloqueos
compartidos, pero no exclusivos. Este tipo de bloqueo se utiliza cuando las
transacciones no necesitan actualizar datos, pero quieren impedir cualquier
modificacin de stos mientras son consultados. Los bloqueos compartidos
permiten que varias transacciones simultaneas lean (SELECT) un recursos
en situaciones control de simultaneidad pesimista. Ninguna otra accin
podr modificar los datos mientras el bloqueo compartido exista en el
recurso. Los bloqueos compartidos en un recurso se liberan tan pronto
como finaliza la operacin de lectura a menos que se haya establecido el
nivel de aislamiento de la transaccin como REPEATABLE READ o mas
alto, o bien se utilice una sugerencia de bloqueo para mantener los
bloqueos compartidos durante la transaccin.
Con SELECT ... FROM ... LOCK IN SHARE MODE, se aplica bloqueo compartido en
todos los registros ndices encontrado.
Los bloqueos pueden colocarse, ya sea de manera automtica por el DBMS o por
medio de un comando emitido al DBMS partiendo del programa de aplicacin del
usuario de la consulta. Los bloqueos colocados por el DBMS se llaman bloqueos
implcitos, los que son colocados por comando se llaman explcitos.
Los bloqueos tambin varan en tipo:

14 de jun.
15
x Un bloqueo exclusivo cierra el elemento a un acceso de cualquier tipo.
Ninguna otra transaccin puede leer o modificar los datos.
x Un bloqueo compartido cierra elementos a modificaciones, no a la lectura.
Otras transacciones pueden leer el elemento, siempre y cuando no intenten
modificarlo.
Ejemplos de Transacciones y Concurrencia.
Partiendo del esquema siguiente se presentan las acciones de 2 transacciones
concurrentes.
La tabla a usar para el ejemplo de control de concurrencia es la que se presenta a continuacin:
+-------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| id | int(11) | | PRI | 0 | |
| debit | float | YES | | NULL | |
+-------+---------+------+-----+---------+-------+
2 rows in set (0.08 sec)

Ejemplo:
T1 T2
mysql> set autocommit=0;
Query OK, 0 rows affected (0.09 sec)
mysql> select * from bank;
+------+-------+
| id | debit |
+------+-------+
| 32 | 999 |
| 64 | 7865 |
+------+-------+
2 rows in set (0.00
sec)

mysql> insert into bank
values(66,3453);
Query OK, 1 row
affected (0.09 sec)

+------+-------+
| id | debit |
+------+-------+
| 32 | 999 |
| 64 | 7865 |
| 66 | 3453 |
+------+-------+
3 rows in set (0.00
sec)

mysql> delete from bank where id=64;
Query OK, 1 row
affected (0.12 sec)

+------+-------+
| id | debit |
+------+-------+
| 32 | 999 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)

mysql> commit;


Query OK, 0 rows
affected (0.00 sec)
+------+-------+
| id | debit |
+------+-------+
| 32 | 999 |
| 64 | 7865 |
+------+-------+
2 rows in set (0.00
sec)

+------+-------+
| id | debit |
+------+-------+
| 32 | 999 |
| 64 | 7865 |
+------+-------+
2 rows in set (0.15
sec)

+------+-------+
| id | debit |
+------+-------+
| 32 | 999 |
| 64 | 7865 |
+------+-------+
2 rows in set (0.00
sec)

mysql> commit;



+------+-------+
| id | debit |
+------+-------+
| 32 | 999 |

14 de jun.
16
+------+-------+
| id | debit |
+------+-------+
| 32 | 999 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)
mysql> rollback;
Query OK, 0 rows
affected (0.00 sec)
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)
mysql> rollback;
Query OK, 0 rows
affected (0.01 sec)

Query OK, 0 rows
affected (0.01 sec)

mysql> select * from bank where id=32
for update;
+------+-------+
| id | debit |
+------+-------+
| 32 | 999 |
+------+-------+
1 row in set (0.00 sec)

mysql> rollback;
Query OK, 0 rows
affected (0.00 sec)

+------+-------+
| id | debit |
+------+-------+
| 32 | 999 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)

+------+-------+
| id | debit |
+------+-------+
| 32 | 999 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)

mysql> commit;
Query OK, 0 rows
affected (0.07 sec)
+------+-------+
| id | debit |
+------+-------+
| 32 | 666 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.01
sec)

Query OK, 0 rows
affected (0.00 sec)

mysql> update bank set debit=666 where
id=32;
.
.
.
.
.
.
.Wait unlock
.
.
.
.
id=32;
Query OK, 1 row
affected (13.02 sec)
Rows matched: 1
Changed: 1 Warnings: 0

+------+-------+
| id | debit |
+------+-------+
| 32 | 666 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)
mysql> commit;
Query OK, 0 rows
affected (0.07 sec)

+------+-------+
| id | debit |
+------+-------+
| 32 | 666 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.01
sec)

+------+-------+
| id | debit |
+------+-------+
| 32 | 666 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.01
sec)


14 de jun.
17
Query OK, 0 rows
affected (0.00 sec)

lock in share mode;
+------+-------+
| id | debit |
+------+-------+
| 32 | 666 |
+------+-------+

id=32;
ERROR 1213 (40001): Deadlock found
when trying to get lock;
Try restartingtransaction

>T1 tiene bloqueado a 32, T2 espera la
liberacion
>al hacer el update en T1 ahora T1
espera a T2
>por lo tanto se produce un deadlock
>el dbms hace rollback en T1 (ultimo
en espera) y procesa T2

+------+-------+
| id | debit |
+------+-------+
| 32 | 666 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)

+------+-------+
| id | debit |
+------+-------+
| 32 | 666 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)
mysql> rollback;
Query OK, 0 rows
affected (0.00 sec)
+------+-------+
| id | debit |
+------+-------+
| 32 | 777 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.01
sec)
Query OK, 0 rows
affected (0.00 sec)

id=32;
.
.
.
.>Wait unlock
.
.
.
.
.
.
.
.
.
.
.
.
.
.
id=32;
Query OK, 1 row
Rows matched: 1
+------+-------+
| id | debit |
+------+-------+
| 32 | 777 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)
mysql> commit;
Query OK, 0 rows
affected (0.00 sec)

+------+-------+
| id | debit |
+------+-------+
| 32 | 777 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)

Query OK, 0 rows
affected (0.00 sec)

for update;
+------+-------+
| id | debit |
+------+-------+
| 32 | 777 |
+------+-------+
Query OK, 0 rows
affected (0.00 sec)

for update;
.
.
.
.
.

14 de jun.
18

id=32;
Query OK, 1 row
affected (0.00 sec)
Rows matched: 1

mysql> commit;
Query OK, 0 rows
affected (0.01 sec)

+------+-------+
| id | debit |
+------+-------+
| 32 | 111 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)

Query OK, 0 rows
affected (0.00 sec)

id=32;
Query OK, 1 row
affected (6.88 sec)
Rows matched: 1
+------+-------+
| id | debit |
+------+-------+
| 32 | 0 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)
mysql> commit;
Query OK, 0 rows
affected (0.00 sec)
+------+-------+
| id | debit |
+------+-------+
| 32 | 0 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)

.
.> Wait unlock
.
.
.
.
.

for update;
+------+-------+
| id | debit |
+------+-------+
| 32 | 111 |
+------+-------+
1 row in set (32.45
sec)

mysql> rollback;
Query OK, 0 rows
affected (0.00 sec)

+------+-------+
| id | debit |
+------+-------+
| 32 | 111 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)

+------+-------+
| id | debit |
+------+-------+
| 32 | 0 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)
Query OK, 0 rows
affected (0.00 sec)

id=32;
.
.
.
.
.
.> Wait unlock
.
.
.
.
Query OK, 0 rows
affected (0.00 sec)
for update;
+------+-------+
| id | debit |
+------+-------+
| 32 | 0 |
+------+-------+

mysql> commit;
Query OK, 0 rows
affected (0.00 sec)


14 de jun.
19
.
id=32;
Query OK, 1 row
affected (3.20 sec)
Rows matched: 1
+------+-------+
| id | debit |
+------+-------+
| 32 | 333 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)
mysql> commit;
Query OK, 0 rows
affected (0.00 sec)
+------+-------+
| id | debit |
+------+-------+
| 32 | 333 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)

+------+-------+
| id | debit |
+------+-------+
| 32 | 0 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)

+------+-------+
| id | debit |
+------+-------+
| 32 | 0 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)
mysql> commit;
Query OK, 0 rows
affected (0.00 sec)
+------+-------+
| id | debit |
+------+-------+
| 32 | 333 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)

Query OK, 0 rows
affected (0.00 sec)

lock in share mode;
+------+-------+
| id | debit |
+------+-------+
| 32 | 333 |
+------+-------+
id=32;
.
.
.
.
.> Wait unlock
.
.
.
.
.
.
.

id=32;
Query OK, 1 row
Rows matched: 1

+------+-------+
Query OK, 0 rows
affected (0.00 sec)
lock in share mode;
+------+-------+
| id | debit |
+------+-------+
| 32 | 333 |
+------+-------+

id=32;
ERROR 1213 (40001): Deadlock found
when trying to get lock;
Try restartingtransaction

>T2 tiene bloqueado a 32, T1 espera la
liberacion
>al hacer el update en T2 ahora T2
espera a T1
>por lo tanto se produce un deadlock
>el dbms hace rollback en T2 (ultimo
en espera) y procesa T1


14 de jun.
20
| id | debit |
+------+-------+
| 32 | 444 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)
mysql> commit;
Query OK, 0 rows
affected (0.00 sec)
+------+-------+
| id | debit |
+------+-------+
| 32 | 444 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)

+------+-------+
| id | debit |
+------+-------+
| 32 | 333 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)
mysql> commit;
Query OK, 0 rows
affected (0.00 sec)
+------+-------+
| id | debit |
+------+-------+
| 32 | 444 |
| 66 | 3453 |
+------+-------+
2 rows in set (0.00
sec)

lock in share mode;
+----+-------+
| id | debit |
+----+-------+
| 32 | 444 |
+----+-------+
>
> Nadie puede modificar la tupla 32
>

mysql> commit;
Query OK, 0 rows
affected (0.00 sec)

+----+-------+
| id | debit |
+----+-------+
| 32 | 444 |
| 66 | 3453 |
+----+-------+
2 rows in set (1.02
sec)

+----+-------+
| id | debit |
+----+-------+
| 32 | 555 |
| 66 | 3453 |
+----+-------+
2 rows in set (0.01
sec)


id=32;
.
.
.
.
.> Wait unlock
.
.
.
.
.
.
id=32;
Query OK, 1 row
Rows matched: 1

mysql> commit;
+----+-------+
| id | debit |
+----+-------+
| 32 | 555 |
| 66 | 3453 |
+----+-------+
2 rows in set (0.00
sec)

Control de Concurrencia

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Control de Concurrencia

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD DE EL SALVADOR

FACULTAD MULTIDISCIPLINARIA PARACENTRAL

You might also like