ALUMNAS: MARTA ELIDA, FLORES GOMEZ VANESSA ILIANA, URRUTIA AREVALO
MARTES, 14 DE JUNIO DEL 2011 CONTROL DE CONCURRENCIA
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
CONTROL DE CONCURRENCIA
14 de jun. 3 CONTROL DE CONCURRENCIA
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. CONTROL DE CONCURRENCIA
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. CONTROL DE CONCURRENCIA
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. CONTROL DE CONCURRENCIA
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. CONTROL DE CONCURRENCIA
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: CONTROL DE CONCURRENCIA
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. CONTROL DE CONCURRENCIA
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 CONTROL DE CONCURRENCIA
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 CONTROL DE CONCURRENCIA
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 CONTROL DE CONCURRENCIA
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 CONTROL DE CONCURRENCIA
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 CONTROL DE CONCURRENCIA
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: CONTROL DE CONCURRENCIA
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)
mysql> select * from bank; +------+-------+ | 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)
mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 999 | | 66 | 3453 | +------+-------+ 2 rows in set (0.00 sec)
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec)
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 999 | | 64 | 7865 | +------+-------+ 2 rows in set (0.00 sec)
mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 999 | | 64 | 7865 | +------+-------+ 2 rows in set (0.15 sec)
mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 999 | | 64 | 7865 | +------+-------+ 2 rows in set (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.00 sec)
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec)
mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 999 | CONTROL DE CONCURRENCIA
14 de jun. 16 mysql> select * from bank; +------+-------+ | 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)
mysql> set autocommit=0; 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> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 999 | | 66 | 3453 | +------+-------+ 2 rows in set (0.00 sec)
mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 999 | | 66 | 3453 | +------+-------+ 2 rows in set (0.00 sec)
mysql> commit; Query OK, 0 rows affected (0.07 sec) mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 666 | | 66 | 3453 | +------+-------+ 2 rows in set (0.01 sec)
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec)
mysql> update bank set debit=666 where id=32; . . . . . . .Wait unlock . . . . mysql> update bank set debit=666 where id=32; Query OK, 1 row affected (13.02 sec) Rows matched: 1 Changed: 1 Warnings: 0
mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 666 | | 66 | 3453 | +------+-------+ 2 rows in set (0.00 sec) mysql> commit; Query OK, 0 rows affected (0.07 sec)
mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 666 | | 66 | 3453 | +------+-------+ 2 rows in set (0.01 sec)
mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 666 | | 66 | 3453 | +------+-------+ 2 rows in set (0.01 sec)
CONTROL DE CONCURRENCIA
14 de jun. 17 mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec)
mysql> select * from bank where id=32 lock in share mode; +------+-------+ | id | debit | +------+-------+ | 32 | 666 | +------+-------+ 1 row in set (0.00 sec)
mysql> update bank set debit=888 where 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
mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 666 | | 66 | 3453 | +------+-------+ 2 rows in set (0.00 sec)
mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 666 | | 66 | 3453 | +------+-------+ 2 rows in set (0.00 sec) mysql> rollback; Query OK, 0 rows affected (0.00 sec) mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 777 | | 66 | 3453 | +------+-------+ 2 rows in set (0.01 sec) mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec)
mysql> update bank set debit=777 where id=32; . . . .>Wait unlock . . . . . . . . . . . . . . mysql> update bank set debit=777 where id=32; Query OK, 1 row affected (23.10 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 777 | | 66 | 3453 | +------+-------+ 2 rows in set (0.00 sec) mysql> commit; Query OK, 0 rows affected (0.00 sec)
mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 777 | | 66 | 3453 | +------+-------+ 2 rows in set (0.00 sec)
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec)
mysql> select * from bank where id=32 for update; +------+-------+ | id | debit | +------+-------+ | 32 | 777 | +------+-------+ mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec)
mysql> select * from bank where id=32 for update; . . . . . CONTROL DE CONCURRENCIA
14 de jun. 18 1 row in set (0.00 sec)
mysql> update bank set debit=111 where id=32; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0
mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 111 | | 66 | 3453 | +------+-------+ 2 rows in set (0.00 sec)
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec)
mysql> update bank set debit=000 where id=32; Query OK, 1 row affected (6.88 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 0 | | 66 | 3453 | +------+-------+ 2 rows in set (0.00 sec) mysql> commit; Query OK, 0 rows affected (0.00 sec) mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 0 | | 66 | 3453 | +------+-------+ 2 rows in set (0.00 sec)
. .> Wait unlock . . . . .
mysql> select * from bank where id=32 for update; +------+-------+ | id | debit | +------+-------+ | 32 | 111 | +------+-------+ 1 row in set (32.45 sec)
14 de jun. 19 . mysql> update bank set debit=333 where id=32; Query OK, 1 row affected (3.20 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 333 | | 66 | 3453 | +------+-------+ 2 rows in set (0.00 sec) mysql> commit; Query OK, 0 rows affected (0.00 sec) mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 333 | | 66 | 3453 | +------+-------+ 2 rows in set (0.00 sec)
mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 0 | | 66 | 3453 | +------+-------+ 2 rows in set (0.00 sec)
mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 0 | | 66 | 3453 | +------+-------+ 2 rows in set (0.00 sec) mysql> commit; Query OK, 0 rows affected (0.00 sec) mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 333 | | 66 | 3453 | +------+-------+ 2 rows in set (0.00 sec)
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec)
mysql> select * from bank where id=32 lock in share mode; +------+-------+ | id | debit | +------+-------+ | 32 | 333 | +------+-------+ 1 row in set (0.00 sec) mysql> update bank set debit=444 where id=32; . . . . .> Wait unlock . . . . . . .
mysql> update bank set debit=444 where id=32; Query OK, 1 row affected (30.83 sec) Rows matched: 1 Changed: 1 Warnings: 0
mysql> select * from bank; +------+-------+ mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) mysql> select * from bank where id=32 lock in share mode; +------+-------+ | id | debit | +------+-------+ | 32 | 333 | +------+-------+ 1 row in set (0.00 sec)
mysql> update bank set debit=777 where 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
CONTROL DE CONCURRENCIA
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) mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 444 | | 66 | 3453 | +------+-------+ 2 rows in set (0.00 sec)
mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 333 | | 66 | 3453 | +------+-------+ 2 rows in set (0.00 sec) mysql> commit; Query OK, 0 rows affected (0.00 sec) mysql> select * from bank; +------+-------+ | id | debit | +------+-------+ | 32 | 444 | | 66 | 3453 | +------+-------+ 2 rows in set (0.00 sec) mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec)
mysql> select * from bank where id=32 lock in share mode; +----+-------+ | id | debit | +----+-------+ | 32 | 444 | +----+-------+ 1 row in set (0.00 sec) > > Nadie puede modificar la tupla 32 >