Transacciones UNIVERSIDAD DE EL SALVADOR FACULTAD MULTIDISCIPLINARIA PARACENTRAL DEPARTAMENTO DE INFORMATICA INGENIERIA DE SISTEMAS INFORMATICOS

TRANSACCIONES

DOCENTE: ING. HERBERT MONGE.

INTEGRANTES: BR. AGUILAR NAVARRETE, RONALD ARQUIMIDES BR. LOPEZ MOLINA, JENNIFFER BEATRIZ BR. MIRANDA AYALA, KARINA YESENIA

SAN VICENTE, 31 DE MAYO DE 2011.

1 Universidad de El Salvador, Bases de Datos 2011

Transacciones INTRODUCCION.

Las transacciones hoy en día corresponden

un detalle muy especial para el buen

funcionamiento de una base de datos, es por ello que cada gestor de base de datos las maneja de una manera muy diferente; una transacciones se define como una pequeña serie de instrucciones que permite mantener el ACID en la base de datos, es por ello que cada gestor de base de datos se encarga de que en la realización de dichas transacciones se cumpla el ACID y así no dañar la base de datos o dejar en un estado inconsistente. En este documento se definirá una serie de conceptos importante para la compresión de las transacciones, los aspectos que están tratan de evitar, como le podemos sacar provechos a las misma, y una introducción al concepto que hace referencia al ACID, también se trataran aspecto fundamentales como la multiprogramación, un aspecto importante para lo que son las transacciones, así como la manera de aplicar la serializarían en las transacción, ya que al momento de combinar dicha técnica podremos estar seguro de que nuestra base de datos no se encontrara en un estado inconsistente o entre en un proceso de deterioro. Un aspecto muy importante que se debe de cubrir cuando se hace alusión a las transacciones, son los candados que las misma puedan requerir, es por ello que estos no se escapan al documento ese mencionan en un apartado, donde se pueden señalar los diferentes candados que pudiesen ocurrir y la manera de cómo tratar de evitar que se lleven acabo algunos de ellos. Y como ejemplos del uso de transacciones nos basaremos en el Gestor de bases de datos de Oracle® Mysql Server, en el mencionaremos como los diferente tipos de bases de datos que maneja este gestor interaccionan con las transacciones.

2 Universidad de El Salvador, Bases de Datos 2011

Transacciones

OBJETIVOS

General  Introducir el concepto de transacciones en el trato de las bases de datos, los problemas que surgen con las mismas, las propiedades que tienen, la manera adecuado de su uso, la aplicación de la serializacion en conjunción con las transacciones y el uso de las mismas en un Gestor de bases de datos Predeterminado.

Específicos.      Definir el concepto de transacciones y sus propiedades en el área de Bases de Datos Aplicar el concepto de ACID y como este puede llevarnos a tener una mejor base de datos. Comprender el concepto de serializacion y como este puede llevarnos a que se cumplan aspecto importante del ACID. Dar a conocer el concepto de candados que surge cuando se ejecuta una transacción y los diferentes modos que existen de los mismos. Demostrar mediantes ejemplos la utilización de las transacciones en el Gestor de Bases de Datos MySql.

3 Universidad de El Salvador, Bases de Datos 2011

en forma indivisible o atómica. stuId. El concepto de transacción es fundamental para entender tanto la recuperación como el control de concurrencia. No importa el cuidado con que se diseñe y cree una base de datos. department. Puede ser un programa completo. dado el stuId. firstName. Ambas medidas son necesarias para impedir que los datos sean inconsistentes o se pierdan. Una transacción se puede considerar una unidad lógica de trabajo en la base de datos. Propiedades de las transacciones. credits) Faculty (facId. es decir. schedule. Localizar el registro 4 Universidad de El Salvador. fecName. La figura 1 resume los pasos de esta transacción. Involucra cualquier número de operaciones en la base de datos. room) Enroll (classNumber. fragmento de programa o comando único. grade) Una transacción sencilla ejecutada en esta base de datos podría actualizar el número de créditos en un registro Student. major. facId. Esta tarea implica localizar en el disco el bloque que contiene el registro Student deseado. Bases de Datos 2011 . llevar el bloque al búfer. igual que antes pero también es necesario encontrar todos los registros Enroll que tenga el antiguo stuid para actualizarlos. rank) Class (classNumber. escribir el bloque actualizado en el disco.Transacciones TRANSACCIONES Una transacción en un Sistema de Gestión de Bases de Datos (SGBD). para llevar su bloque al búfer para actualizar el stuid en el búfer y escribir la actualización en el disco. Es obvio que se necesita localizar el registro Student apropiado. El control de la concurrencia es la capacidad de administrar procesos simultáneos que acceden a la base de datos sin que interfieran entre sí. Utilizaremos como ejemplo la base de Datos Universityy se usará en esquema siguiente: Student (stuId. y finalmente. a menos que haya controles apropiados es el proceso de restaurarla a su estado correcto en caso de falla. Una transacción más complicada sería cambiar el stuid asignado a un estudiante en particular. es un conjunto de órdenes que se ejecutan formando una unidad de trabajo. es fácil que se dañe o destruya. lastName.

durante la actualización de stuId habrá un momento en que una concurrencia de stuId contenga el valor nuevo y otra el viejo. se dice que la transacción fue comprometida (commit). Si se ejecuta hasta el final con éxito. Hay dos formas de finalizar o terminar una transacción. dicha transacción fue deshecha. Por ejemplo. es esencial que la base de datos se restaure al estado consistente en que estaba antes de comenzar la transacción. Bases de Datos 2011 . ya que una transacción parcial dejaría la base de datos en un estado inconsistente. La transacción es un proceso atómico. Mientras la transacción este en progreso. la transacción es abortada. Sin embargo. todas las concurrencias coincidirán. Si se aborta una transacción. y labase de datos se lleva a un nuevo estado consistente. Una transacción siempre debe llevar a la base de datos de un estado consistente a otro consistente. Una transacción es el conjunto de operaciones necesarias para llevar a cabo una unidad lógica de trabajo. Es decir.Transacciones Llevar el bloque al búfer XX Volver a escribir el campo de los créditos en el búfer XX Escribir en el disco el bloque modificado Figura 1 (etapas en una transacción simple) Si estas actualizaciones no se hicieran entonces se tendría un estado inconsistente de la base de datos. En este caso. a fin de llevar a la base de datos a un nuevo estado consistente. No se permite ejecutar solo una parte de la transacción. al final de la transacción. una sola unidad del “todo o nada”. La otra posibilidad es que la transacción no se ejecute con éxito. se ejecutan todas las operaciones de la transacción o ninguna. estado en que los datos son contradictorios. es permisible tener un estado temporal inconsistente. esto quiere decir que se retrocede y al mismo tiempo se deshace (rollback)cada una de las operaciones realizadas por la 5 Universidad de El Salvador.

y que el sistema sea capaz de hacer los cambios requeridos en la base de dato. El estado activo de la transacción comienza con el enunciado BEGIN TRANSACTION y continua hasta que el programa de aplicación aborta o concluye con éxito. para delimitar transacciones. el DBMS verifica que la transacción no viole los protocolos de control de concurrencia. y ROLLBACK si no lo hace. Por otro lado. En ciertos DML existen las palabras BEGIN TRANSACTION. Si no se utilizan estos delimitadores. y en este último case se llega a ENDTRANSACTION. si ocurriera un error fatal mientras la transacción actual está activa. Si se hubieran hecho cualesquiera actualizaciones a la base de datos. COMMIT. por lo general se consideran a todo el programa como una transacción única. es decir se realiza un ROLLBACK a la transacción. es responsabilidad del programador identificar el comienzo y final de cada transacción. en cuyo caso se ejecuta COMMIT. ABORT y ROLLBACK. END TRANSACTION. Si se decide que la transacción comprometida fue un error. Bases de Datos 2011 . toda vez que el sistema de administración de la base de datos no es capaz de determinar cuáles actualizaciones constituyen una transacción única. Sin embargo. una transacción abortada que haya sido deshecha puede ser reiniciada en algún momento futuro y. podría ejecutarse exitosamente y ser comprometida. Termina la transacción Comienza la transacción Transacción activa Abortar Comprometida parcialmente Comprometida Fin Fallo Abortada Figura 2 (Diagrama del estado de la transacción) Por lo general. se debe ejecutar otra transacción compensadorapara revertir sus efectos.Transacciones transacción hasta el inicio. Durante esta etapa de comprometimiento parcial. se deshacen. si hubiera algún 6 Universidad de El Salvador. la transacción se compromete. La figura 2 ilustra los estados posibles de una transacción. Si no surgen problemas. en función de cual haya sido la causa de la falla. Una transacción comprometida no se puede abortar. Aun después de que la transacción haya terminado con éxito. y el DBMS (sistema de gestión de base de datos)se prepara para comprobar que la transacción fue comprometida. y el sistema ejecuta de manera automática la instrucción COMMIT cuando el programa finaliza correctamente. se etiqueta como fracaso y se aborta. o alguna restricción.

Para garantizar que la base de datos mantiene un estado correcto a pesar de una falla de concurrencia o del sistema. El subsistema de recuperación del DBMS mantiene un registro. por lo general llamadas ACID. integridad o falla del sistema mientras se está en el estado de comprometimiento parcial. que es un acrónimo en ingles de las propiedades siguientes:  Atomicidad. para lo que utiliza la bitácora de las transacciones. el DBMS debe ser capaz de cancelar transacciones que no terminen con éxito. el resultado en conjunto de todas las transacciones también será un estado consistente. La propiedad de aislamiento requiere que el efecto final sea como si las transacciones se hubieran ejecutado una después de la otra en vez de ejecutarse en forma concurrente. Consistencia. El usuario es responsable de asegurar que su transacción. es decir. Para garantizar esta propiedad.Transacciones problema con el control de concurrencia. Sin embargo. es posible que la transacción se etiquete como fracaso y se aborte. si se ejecutara por sí sola. el cual se utiliza al deshacer la transacción. el DBMS debe asegurar que sus efectos se registren de manera permanente en la base de datos. aun si el sistema fallara antes de que se hubieran escrito en la base de datos los registros involucrados por la transacción. todas las transacciones deben mostrar cuatro propiedades importantes.    Necesidad del control de la concurrencia. El subsistema de recuperación es responsable de garantizar la persistencia de los datos. Aislamiento. Si una transacción ha sido comprometida. Si las transacciones se ejecutan una a la vez. Bases de Datos 2011 . en forma serial. no hay ningún problema de interferencia entre ellas. y anular sus efectos sobre la base de datos. La transacciónesuna sola unidad de “todo o nada”. Durabilidad. Es trabajo del subsistema de control de concurrencia del DBMS garantizar la consistencia cuando se ejecutan al mismo tiempo transacciones múltiples. Se ejecuta todo el conjunto de acciones o ninguna. El sistema de control de concurrencia tiene que garantizar el aislamiento. es 7 Universidad de El Salvador. deje a la base de datos en un estado consistente. Como cada transacción de manera aislada deja a la base de datos en un estado consistente. Uno de los objetivos principales al desarrollar una base de datos es crear un recurso de información que compartan muchos usuarios. de todas las transacciones escritas en la base de datos. llamado bitácora. de modo que cada transacción se comprometa antes de que comience la siguiente. Es posible que varias transacciones se ejecuten al mismo tiempo con sus operaciones intercaladas.

El sistema comienza a ejecutarla hasta que alcanza una operación de entrada o salida. los sistemas de control de entrada y salida manejan estas operaciones en forma independiente. actualización no comprometida. pero pueden ejecutarse simultáneamente las operaciones de otra transacción durante la ejecución de la primera. Jill recibe su salario y decide depositar 100 dólares en la cuenta. Jack necesita gastar algo de dinero y decide retirar 50 dólares de la cuenta. Mientras se ejecutan estas. la intercalación de sus operaciones puede producir un resultado incorrecto. si se realizan de manera concurrente el saldo final puede ser incorrecto. o uno los actualiza mientras otro los lee. Una secuenciaes una lista de las acciones que realiza un conjunto de transacciones y muestra el orden en que se llevan a cabo. mientras el procesador principal ejecuta otras operaciones. es posible que haya conflictos. Se preserva el orden de las operaciones de cada transacción. La figura 3 muestra la programación de la ejecución concurrente que da como resultado un saldo de 1100 dólares. cuando dos usuarios tratan de hacer actualizaciones simultáneas a los mismos datos. De esta manera. el procesador principal. donde se indican las operaciones de esa transacción. y datos fantasmas. Entre tanto. lo que resulta en la intercalación de las operaciones. Sin embargo. cambia a la segunda transacción y realiza cualesquiera operaciones que pueda ejecutar de esta transacción. Problema de la actualización perdida Suponga que Jack y Jill tienen una cuenta de ahorros mancomunada con saldo de 1000 dólares. Después. Sin embargo. Si estas transacciones se ejecutaran de manera serial. las unidades secuenciales de tiempo a fin de 8 Universidad de El Salvador. hasta terminar todas las operaciones de las dos transacciones. t2. lectura irrepetible. en una sucursal diferente. Algunos ejemplos de los problemas potenciales ocasionados por la concurrencia son la actualización perdida. las operaciones de las dos transacciones son intercaladas. que de otra manera estaría ocioso durante la entrada y salida. una después de otra sin intercalación de sus operaciones. el control regresa a la primera transacción y sus operaciones se ejecutan hasta que otra vez llegue a una operación de entrada o salida. y así sucesivamente. Bases de Datos 2011 . sus transacciones pueden correr de manera concurrente sin ningún problema. Si todos los usuarios sólo van a leer datos. en una sucursal cerca de su trabajo. A continuación se ilustran los tres primeros problemas para mostrar el orden cronológico en que se realizan las operaciones. En la secuencia se denota como t1. Multiprogramación significa tener dos o más programas o transacciones en proceso al mismo tiempo. En dicha secuencia se tiene una columna para cada transacción. análisis inconsistente.Transacciones frecuente que los usuarios necesiten acceder a los datos en forma concurrente. el balance final seria 1050 dólares sin que importara cual se hubiera hecho primero.. Por ejemplo. etc. Pero aun cuando ambas sean perfectamente correctas en sí mismas. Tales sistemas permiten que dos o más transacciones se ejecuten de manera simultánea. de modo que se llevan a cabo algunas de la primera y luego otras de la segunda.

Este también se conoce como problema de la lectura sucia. la transacción INTERES calcula el interés para una cuenta de ahorro. la actualización de Jack se pierde. . como se refleja en la columna de BAL. Cada transacción ignora cualquier cambio hecho a la base de datos. La figura 4 muestra la secuencia de un ejemplo de actualización no comprometida que genera un error.Transacciones mostrar el orden cronológico de las operaciones. sobre la actualización de Jack. De acuerdo con la secuencia. HORA t1 t2 t3 t4 t5 t6 t7 t8 Transacción de Jack BEGIN TRANSACTION read BAL(lee 1000) . estas operaciones involucran ya sea llevar un valor de la base de datos en el búfer (leer) o escribir un nuevo valor en el bloque de la base de datos en el búfer (escribir) para luego copiar en la base de datos el bloque modificado. 9 Universidad de El Salvador. . se habría evitado este problema. Su transacción suma 100 dólares y luego escribe un valor nuevo de 1100 dólares en la base de datos. están separados de los atributos de ésta. En el momento t5. . lo que invalida el dato que está usando la segunda. . que por sencillez supondremos tienen el mismo nombre que los atributos de la base de datos a la que corresponden. . Aquí. BAL = BAL – 50(950) write BAL(950) COMMIT Transacción de Jill BEGIN TRANSACTION read BAL(lee 1000) . La transacción de Jack resta 50 dólares de BAL y luego. La transacción de Jill hace lo mismo un poco más tarde. que no ha leído. no el nuevo. La actualización de una variable de la transacción no tiene efecto en la base de datos hasta que se encuentra un comando write<atributo>. El valor que una transacción lee para una variable es el que utiliza para los cálculos. a menos que los haya realizado ella misma. Las variables de la transacción. manda que se escriba en la base de datos. en t5. SALDO 1000 1000 1000 950 950 1100 1100 El problema de la actualización no comprometida Este problema ocurre con transacciones concurrentes cuando se permite que la primera modifique un valor que luego es leído por la segunda. Bases de Datos 2011 . . Si se hubiera retrasado la lectura de Jill hasta que hubiera terminado la actualización de Jack. la transacción de Jack lee un valor de 1000 dólares para la variable BAL en el momento t2. ya que se genera por leer datos sucios. Como se aprecia en la secuencia. que son resultados intermedios de una transacción no comprometida. la transacción de Jill todavía usa el valor de BAL que leyó. y después la primera deshace la actualización. BAL = BAL + 100(1100) . Las únicas operaciones que involucran a la base de datos se indican explícitamente como read<atributo> o write<atributo>. write BAL (1100) COMMIT Figura 3. con una tasa de 5%. en t3. Como se aprecia en la figura 3.

INTERES Transacción . . Observe que esta transacción no modifica las cuentas sino sólo las lee. . DEPÓSITO se deshace. Suponga que el saldo inicial en la cuenta es de 1000 dólares. . ROLLBACK . la transacción TRANSFER transfiere 1000 dólares de la cuenta A a la C. . y son: 10 Universidad de El Salvador. por lo que en el momento t6 se restaura el valor original de 1000 dólares como resultado de deshacer DEPÓSITO. pero esta se deshace. .Transacciones mientras que la transacción DEPÓSITO aporta 1000 dólares a la cuenta. . esta transacción se ejecuta y compromete correctamente. . BEGIN TRANSACTION read BAL (2000) BAL = BAL * 1. La figura 5 contiene la secuencia que muestra el resultado incorrecto que pudiera producirse. que suma dos veces los 1000 dólares. . . write BAL (2100) COMMIT Figura 4. Al mismo tiempo. una cuando está en la cuenta A y otra cuando llega a la cuenta C. la cantidad que almacenaría INTERES sería de 2100 dólares. Como INTERES se calculó con el saldo incorrecto. e INTERES también ignora que se deshizo DEPÓSITO.05(2100) . Bases de Datos 2011 . . interfiere con la transacción SUMBAL. La transacción SUMBAL calcula la suma del saldo de todas las cuentas. se escribe el valor calculado por INTERES. . . La razón de deshacer DEPÓSITO puedo ser que la transacción era errónea. Existen otros dos problemas famosos que puedan surgir debido a la concurrencia. lo que significa que el estado de la base de datos no debe mostrar ningún efecto debido a DEPÓSITO. Sin embargo. Suponga que se desea encontrar el saldo total de las cuentas de ahorro pero se permite que durante esa transacción se realicen depósitos. En t8. el valor final de éste también será incorrecto. Para que el ejemplo sea pequeño se supondrá que solo hay tres cuentas. . o era el resultado de una caída del sistema. HORA t1 t2 t3 t4 t5 t6 t7 t8 t9 DEPOSITO Transacción BEGIN TRANSACTION read BAL(1000) BAL = BAL + 1000(2000) write BAL (2000) . Observe que DEPÓSITO ignora que INTERES ha leído lo que escribió. Saldo 1000 1000 1000 2000 2000 2000 1000 2100 2100 El problema del análisis inconsistente El problema del análisis inconsistente ocurre cuando una transacción lee varios valores pero una segunda transacción actualiza algunos de ellos durante la ejecución de la primera. . retiros y trasferencias. Si DEPÓSITO actualizara en verdad el valor del saldo para que fuera 2000 dólares antes de que INTERES lo leyera. Sin embargo.

Si las transacciones que aparecen en la figura 3 se hubieran ejecutado de manera serial. por lo que tampoco habría interferido entre sí. solo hay dos posibilidades de ejecuciones seriales: primero se termina la transacción A y después se hace la B. 11 Universidad de El Salvador. o bien se concluye la B para luego ejecutar la A. sin que importara cual se hubiera realizado primero. . que sucede cuando una primera transacción lee un conjunto de renglones (por decir. en una ejecución serial no hay interferencias entre las transacciones. que ocurre cuando una primera transacción lee un registro. Problema de los datos fantasma. la transacción DEPOSITO se habría deshecho antes de que comenzara la transacción INTERES. sin cualquier intercalación de operaciones. . los resultados habrían sido correctos. read BAL_A(5000) SUM = SUM+BAL_A (5000) read BAL_B(5000) SUM = (10000) . y luego la primera transacción vuelve a leer el registro y obtiene un valor diferente. . puesto que en cualquier momento dado solo una se está ejecutando. otra transacción inserta un reglón y después la primera lee otra vez los renglones y detecta el renglón nuevo. . Si las transacciones de la figura 4 se hubieran realizado de manera serial. Hora t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 SUMBAL BEGIN TRANSACTION SUM = 0. SUM+BAL_B TRANSFER SALDO DE A 5000 5000 5000 5000 5000 4000 4000 4000 4000 4000 4000 4000 4000 SALDO DE B 5000 5000 5000 5000 5000 5000 5000 5000 5000 5000 5000 5000 5000 SALDO DE C 5000 5000 5000 5000 5000 5000 5000 5000 6000 6000 6000 6000 6000 SUMA 16000 16000 BEGIN TRANSACTION . Si A y B son dos transacciones. Bases de Datos 2011 . después otra escribe un valor nuevo para éste. raed BAL_A(5000) BAL_A=BAL_A1000(4000) write BAL_A(4000) read BAL_C(5000) BAL_C BAL_C+1000(6000) write BAL_C(6000) COMMIT = Read BAL_C(6000) SUM = SUM BAL_C(16000) Write SUM(16000) COMMIT + Figura 5. la del depósito o la del retiro.Transacciones Problema de lectura irrepetible. las tuplas en el resultado de una consulta). o esta habría concluido antes de que comenzara DEPOSITO. SERIALIZACION Una ejecución serial de las transacciones significa que estas se ejecutan una después de otra.

Si una transacción escribe sobre un ítem de datos y otro lee o escribe sobre este mismo ítem. Si dos transacciones operan (ya sea lectura o escritura) sobre los ítems de datos. por lo que se considera que toda ejecución serial es correcta aun cuando pueda producirse resultados diferentes. entonces el orden de ejecución si es importante.Al tener ejecuciones seriales. No importa la secuencia serial que se elija. no hay conflicto y no es importante el orden. ellas no entran en conflicto y el orden no es importante. no hay garantía que los resultados de todas las posibles ejecuciones seriales de un conjunto dado de transacciones sean idénticos. En la mayoría de los casos. y producir un estado de la base de datos que pudiera haber sido generado por una verdadera ejecución serial. Los tres problemas descritos se originaron al ejecutarse concurrentemente y dejaron a la base de datos en un estado inconsistente. Por ejemplo. hay un conflicto entre dos operaciones si son verdaderos todos los enunciados siguientes:    Pertenecen a transacciones diferentes Acceden al mismo tiempo a los datos Al menos una escribe en el mismo ítem Una ejecución seriable de transacciones establece una secuencia de operaciones conflictivas en la misma manera que lo haría una ejecución serial.Transacciones En la figura 5 si la transacción TRANSFER se hubiera pospuesto hasta que terminara la transacción SUMINT. Bases de Datos 2011 . Sin embargo. siempre y cuando sus resultados sean correctos y no tengan que esperar demasiado. esta nunca producirá un estado inconsistente de la bases de datos. en la banca importa si INTERES de una cuenta se calcula antes o después de que se haga un depósito grande. si produce los mismos resultados que una ejecución serial. El objetivo es encontrar formas de permitir que las transacciones se ejecuten de manera concurrente mientras se asegura que no interfieren una con otra. por lo que los resultados de la 12 Universidad de El Salvador. los resultados habrían sido correctos. Una ejecución serial no habría originado que surgieran estos problemas. Es esencial garantizar la seriabilidad de las transacciones concurrentes a fin de garantizar la consistencia e integridad de la base de datos. son importantes los factores siguientes:    Si dos transacciones únicamente leen los ítems de datos. se dice que la secuencia es seriable. Entonces. Para N transacciones hay n! posibles secuencias seriales. a los usuarios no les importa el orden en que se ejecutan sus transacciones. Si un conjunto de transacciones se ejecuta de manera concurrente. separados completamente.

el arco se dibuja de Ti a Tj Si Ti escribe X. Para construir dicho grafo se dibuja un nodo para cada transacción.…Tn. y después Tj escribe X. Observe que en (a). la figura 6(c) presenta una secuencia seriable que es equivalente en cuanto al conflicto a la primera secuencia serial S. el arco se dibuja de Ti a Tj Si Ti lee X. Este tipo de seriabilidad se denomina conflicto seriable. Puede verificar que las dos secuencias seriales dan resultados diferentes. Se puede determinar si una secuencia es del tipo de conflicto seriable por medio de examinar el orden de todas sus lecturas y escrituras conflictivas. S. y compararlas con el orden de las mismas lecturas en las secuencias seriales de las transacciones.T. el arco se dibuja de Ti a Tj S es seriable si el grafo de precedencia no tiene ciclos. También note que aquí no son equivalentes las dos secuencias seriales. se dibuja un arco de TRANSFER a SUMBAL. La figura 6 ilustra dos secuencias. existe una técnica grafica llamada grafo de preferencias. y observar los valores finales que arrojan. Como SUMBAL lee BAL_A y luego TRANFER escribe BAL_A. La figura 7 muestra un grafo de precedencias para la secuencia de la figura 5. lo que da como resultado un ciclo que demuestra que la secuencia no es seriable. y después Tj lee X. Un ciclo es una trayectoria que comienza en un nodo particular y termina en este mismo. Sin embargo. y S lee y escribe y antes de que lo haga T. S lee y escribe x antes de que T la lea y la escriba. en la secuencia seriable en (c) se preserva el mismo orden de lecturas y escrituras. La figura 6(a) muestra la secuencia serial S.T. y después Tj escribe X. una serial y la otra seriable para dos transacciones S y T. se dibuja un arco de SUMBAL a TRANSFER.T. 13 Universidad de El Salvador. Bases de Datos 2011 . Los arcos dirigidos se dibujan como sigue:    Si Ti escribe X. Como TRANSFER escribe BAL_Cny después SUMBAL la lee. a fin de determinar s el orden coincide con al menos una. que permite determinar si una secuencia es de conflicto seriable. mientras que la figura 6(b) presenta la secuencia serial T. T1. La lectura y escritura conflictiva de los ítems de datos ocurren en el mismo orden en la secuencia seriable que en la secuencia serial S. pero ambas se consideran correctas y dejaría la base de datos en un estado consistente.Transacciones ejecución concurrente son los mismos que los de al menos una de las posibles ejecuciones seriales. por medio de la asignación de valores iníciales a x y y.T2.

no es posible ninguna secuencia serial. Siempre que haya un arco de Ti a Tj. Se utiliza una herramienta llamada programador de actividades para que las operaciones se ejecuten de inmediato. Si se rechaza la operación de una transacción. lo usual es obtener una secuencia parcial del grafo. escriba Ti antes de Tj en la secuencia serial. es posible utilizar el grafo de precedencias para encontrar una secuencia serial equivalente con el análisis de los arcos del grafo.Transacciones Hora t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 t12 t13 t14 t15 t16 S BEGIN TRANS read x x=x*3 write x read y y=y+2 write y COMMIT T S T BEGIN TRANS read x x=x+2 write x read y y=y+5 write y COMMIT S BEGIN TRANS read x x=x*3 write x read y y=y+2 write y COMMIT T BEGIN TRASNS read x x=x*3 write x read y y=y+2 write y COMMIT BEGIN TRANS read x x=x+2 write x read y y=y+5 write y COMMIT (a)En serie: S. Si varios nodos aparecen en el grafo. el candado es el que se utiliza con más frecuencia. el DBMS tiene un subsistema de control de concurrencia que es parte del software y no lo controla directamente ni el usuario ni el ABD. 14 Universidad de El Salvador. Si en el grafo hay un ciclo. Una transacción coloca un candado a un objeto de la base de datos para impedir que otra transacción lo modifique. En general. esta se aborta. se retrasen o sean rechazadas.T BEGIN TRANS read x x=x*3 write x read y y=y+2 write y COMMIT (b)En serie: T. CANDADOS Los candados (también llamados boqueos) y las estampas de tiempo son las dos técnicas que generalmente se usan para garantizar la seriabilidad de transacciones concurrentes. Bases de Datos 2011 . para reiniciarla después de que la transacción en conflicto finalice. pero la mayor parte de los sistemas utilizan bloqueo o estampas de tiempo para lograrla. Puede haber varias secuencias seriales. La seriabilidad se logra de varias maneras.S (c) Seriable FIGURA 6 Dos secuencias en serie y otras seriables para las transacciones S y T SUMBAL TRANSFER FIGURA 7 Grafo de precedencia para la figura 5 Si una secuencia es seriable. De estas. dos técnicas que se describen más adelante. ya que a la larga se necesitara que un nodo se preceda a sí mismo.

Si al ítem todavía no se le ha puesto candado mediante otra transacción. pagina o archivo. de otro modo la transacción tendrá que esperar hasta que se libere el candado existente. Si se solicita un candado compartido sobre un ítem que ya tiene un candado compartido. desde toda la base hasta solo un ítem de datos. esa transacción es la única que puede leer y actualizar e ítem. manteniendo una lista de los objetos de la base de datos que tienen candado o por otros medios. una transacción puede liberar explícitamente los candados que tenga antes de que concluya. el sistema determina si la solicitud es compatible con el candad existente. si la primera transacción no tiene candado. Si una transacción tiene un candado exclusivo sobre un ítem. La transacción 2 solicita un La transacción 2 solicita un candado compartido candado exclusivo La transacción 1 no tiene Si Si candado La transacción 1 tiene un Si No candado compartido La transacción 1 tiene un No No candado exclusivo FIGURA 8 Matriz de compatibilidad de candados. Si un sistema utiliza candados. La figura 8 ilustra una matriz decompatibilidad de candados. 15 Universidad de El Salvador. De este modo. Si la primera transacción tiene un candado compartido. Si una transacción tiene un candado compartido sobre un ítem. Todas las demás solicitudes serán denegadas. o granulidad del candado. no uno exclusivo. en la segunda se garantiza solo un candado compartido. El candado se implementa con la inserción de una bandera en el ítem de datos. en la segunda se garantiza un candado compartido o exclusivo.Transacciones Es posible colocar candados a objetos de varios tamaños. esto con la finalidad de impedir que otras transacciones interfieran con ella. Si el ítem ya tiene candado. para indicar que esa porción de la base de datos se encuentra bloqueada. Bases de Datos 2011 . registro. Con frecuencia existen dos tipos de candados: compartidos y exclusivos. este se puede leer pero no actualizar. Si la transacción 1 tiene el tipo de candado indicado a la izquierda. con la solicitud de un candado compartido para permitir solo lectura o un exclusivo para acceso de escritura. Como se ve. la solicitud se garantiza. cualquier transacción que necesite acceder a un ítem de datos primero debe colocar un candado sobre este. Los candados de una transacción se liberan en forma automática cuando esta termina. se garantiza el candado. muchas transacciones pueden tener candados compartidos sobre el mismo objeto al mismo tiempo. y la transacción 2 solicita el tipo de candado indicado en la parte superior de la columna. la matriz muestra si se puede garantizar la solicitud del candado. Además. que indica que tipo de solicitudes de candado se pueden solicitar simultáneamente. El tamaño del objeto determina la finura.

Entonces. Bases de Datos 2011 . Como T tiene un candado exclusivo de b. En el momento t1. Estas llegan a originar una situación llamada candado mortal. la transacción T obtiene un candado exclusivo del ítem b. S y T. en t4. En el procesamiento de una base de datos. durante la ejecución de esta se hacen solicitudes de candado. No es raro que se acceda a registros debido a la relación que tiene con otros registros. que sucede cuando dos transacciones quedan a la espera que se liberen candados controlados por la otra. con frecuencia resulta difícil identificar todo el conjunto de lectura y escritura de una transacción antes de ejecutar esta. en la base de datos University. y en el momento t2. y el que escribe una transacción se denomina conjunto de escritura. También es posible que ocurra un candado mortal que involucre varias transacciones. 16 Universidad de El Salvador. que es mantenido con un candado exclusivo por medio de la transacción S. no es posible predecir con exactitud cuales registros de Enroll. Ninguna transacción puede terminar porque cada una espera un candado que no puede obtener hasta que la otra termine.Transacciones CANDADO MORTAL El conjunto de los ítems que lee una transacción se llama conjunto de lectura. S solicita un candado del ítem b. T solicita un candado compartido (bloqueo S) del ítem a. Class y Faculty se necesitaran. Por ejemplo. la transacción S queda en espera. si se piden el nombre y departamento de todos los profesores de un estudiante en particular. Por lo general es imposible decir por adelantado exactamente cuales registros se relacionaran. Luego. la transacción S pide y obtiene un candado exclusivo (bloqueo X) del ítem a. Como no siempre se puede identificar de antemano los ítem que necesita bloquear una transacción. en t3. la razón es que cada una espera que la otra libere un candado de un ítem que maneja. Hora t1 t2 t3 t4 t5 t6 t7 … Transacción S Transacción T Bloqueo X de a … … Bloqueo X de b Solicitud del bloqueo X de … b En espera Solicitud del bloqueo S de a En espera En espera En espera En espera En espera En espera … … FIGURA 9 Candado mortal con dos Transacciones La figura 9 muestra dos transacciones. que tienen un candado mortal.

Q. que tienen un candado mortal porque Q espera un ítem bloqueado por R. R. R espera un ítem de dato bloqueado por S. las aplicaciones involucradas no son capaces de resolver el problema. en la figura 10 se ilustran cuatro transacciones. En vez de ello.Transacciones Hora Trans Q t1 Bloqueo X por Q1 t2 … t3 t4 t5 t6 t7 t8 t9 … Trans R Trans S Trans T … … … Bloqueo X por … … R1 … … Bloqueo X por … S1 … … … Bloqueo X por T1 Solicitud de bloqueo R1 … … … En espera Solicitud de …. Bases de Datos 2011 . S y T. el sistema tiene que reconocer la existencia del candado mortal y romperlo de algún modo. S espera un ítem bloqueado por T. U V Figura 11 (a) U espera a V U V Figura 11 (b) S y T tienen un candado mortal Q R S T 17 Universidad de El Salvador.10 Candado mortal con cuatro transacciones Por ejemplo. y T espera un ítem bloqueado por Q. … bloqueo S1 En espera En espera Solicitud de … bloqueo T1 En espera En espera En espera Solicitud de bloqueo Q1 En espera En espera En espera En espera … … … … FIGURA 10. Una vez que ocurre un candado mortal.

con el arco dirigido de U a V que indica que U espera un ítem de datos bloqueado por V. Por ejemplo. entonces R obtendría sus ítems de datos solicitados. La victima puede ser la transacción más nueva. muchos sistemas emplean el método de detección y recuperación. la transacción S. lo detecta y lo rompe. T obtendría sus ítem de datos. que permite que suceda el candado mortal pero. Un arco indica que una transacción está a la espera de que otra libere un candado. Obsérvese que debe revisar ciclos de cualquier longitud. la cual tendrá que ser deshecha (roll back). Los esquemas de detección de candado mortal utilizan un grafo de solicitud de recursos o grafo de espera para mostrar cuales son las transacciones a la espera de los recursos bloqueados por otras. La figura 11 (b) muestra un grafo de espera en el que las transacciones S y T están en candado mortal. cada nodo representa una transacción. que no ha realizado mucho trabajo. el grafo de espera es mantenido por el sistema. o la que haya hecho menos actualizaciones. el sistema debe resolver el candado mortal. liberando de esta manera los candados que tenía y permitiendo que las demás transacciones que están en el ciclo puedan continuar. Como es más fácil determinar si hay un candado mortal para romperlo. se agrega un arco al grafo. La figura 11 (c) muestra un grafo de espera que tiene un ciclo de longitud 4. y la detección y recuperación. podría terminar y liberaría sus candados.11 (c) se escogiera a la transacción S como la víctima. la figura 11 (a) muestra dos transacciones U y V. Cuando se presenta un candado mortal. R. de modo que Q también concluiría y. que evitar que ocurra. Lo hace por medio de escoger a una de las transacciones del ciclo como víctima. se dirige a T y regresa a S. situación que se llama inanición. el grafo contendrá un ciclo. Cuando una transacción hace la solicitud de un candado recibe cierto recurso bloqueado. Si en la figura 10. en busca de ciclos. Si el recurso es desbloqueado y obtenido por la transacción. Una vez que se detecta un ciclo. entre otras opciones. Nuevos nodos se agregan al grafo a medida que comienzan nuevas transacciones. ya que existe un ciclo que comienza en S.Transacciones Figura11 (C) Cuatro transacciones con candado mortal Hay dos técnicas generales para manejar un candado mortal: impedirlos . Debe tenerse el cuidado de evitar elegir siempre a la misma transacción como víctima. ya que esa transacción nunca terminara. por último. ya que uno puede involucrar muchas transacciones. En dicho grafo. la 18 Universidad de El Salvador. Este ilustra las transacciones Q. S a T y T a S (por supuesto que también hay un ciclo que comienza en T). que es cuando el sistema busca hacia adelante si una transacción ocasionaría un candado mortal y nunca permitiría que eso ocurriera. una vez ocurrido. Este ciclo es de longitud 2 por que contiene dos arcos o trayectoria dirigidas. El sistema detecta candados mortales por medio de la revisión periódica de su grafo de espera. Entonces. el arco se borra. Bases de Datos 2011 .

De acuerdo con las reglas de este protocolo. cada transacción se desarrolla en dos fases: primero una fase de crecimiento en la que libera todos los candados necesarios para la transacción. Para el acceso de solo lectura basta un candado compartido. BLOQUEO DE DOS FASES Un esquema de bloque que garantiza la seriabilidad es el protocolo de bloqueo de dos fases. y luego una fase de encogimiento en la que libera sus candados. Sin embargo. nunca libera ningún candado hasta que ha alcanzado una etapa en la que no se necesitaran nuevos candados. Para tener acceso a la escritura se requiere un candado exclusivo. No hay ningún requerimiento de que todos los candados se obtengan de manera simultánea. Bases de Datos 2011 .Transacciones víctima. ya no adquiere nuevos candados.  19 Universidad de El Salvador. hace cierto procesamiento y adquiere candados adicionales que necesite. la transacción adquiere algunos candados. Normalmente. Las reglas son:  Una transacción que debe adquirir un candado sobre un ítem antes de operar en este. Una vez la transacción libera uno de los candados. estaría en posibilidad de volver a iniciar y obtendría sus candados en un momento posterior.

Después libero el candado y la transacción de Jill. y lo mantuvo hasta que permitió la modificación de BAL. La transacción de Jack solicito y obtuvo primero el candado. Este problema se llama anulación en cascada. también debe ser deshecha ya que leyó datos sucios. los candados pueden ser liberados antes de comprometerse la transacción (COMMIT). HORA t1 t2 t3 t4 t5 t6 t7 t8 R Comienza Trans Bloqueo X de a Read a (1) a=a+3(4) Write a(4) Unlock a S T a 1 Comienza Trans Solicitud de bloqueo X Comienza Trans de a En espera Solicitud de bloqueo X de a En espera En espera 4 En espera En espera Solicitud de bloqueo X En espera de a Read a(4) En espera 20 Universidad de El Salvador. Observe que ambas transacciones necesitaron un candado exclusivo sobre BAL. que había estado suspendida (en estado de espera) mientras esperaba que el candado se liberara. siempre y cuando no se soliciten nuevos candados después de que se ha liberado cualquiera. Si a una segunda transacción se le permitió leer un valor escrito por la transacción deshecha. Bases de Datos 2011 .Transacciones HORA t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 Transacción de Jack Comienza la transacción Xlock BAL Read BAL(1000) BAL=BAL-50 (950) Write BAL(950) Comprometida/desbloquea BAL Transacción de Bill BAL Comienza transacción RequestXlock BAL Wait (esperar) Wait (esperar) Grant Xlock BAL Read BAL(950) BAL=BAL+100 Write BAL (1050) Comprometida/Desbloquea BAL 1000 1000 950 950 950 950 1050 1050 FIGURA 12 Aplicación de protocolo del bloqueo de dos fases a la figura 3 En la figura 12 se ilustra la manera en que se aplica ala figura 3 el protocolo de bloqueo de dos fases. Un problema que puede surgir es que una transacción no comprometida que haya liberado sus candados sea deshecha. puesto que las dos planeaban actualizarla. pudo lograr este y concluir. En el protocolo estándar de bloqueo de dos fases. descrito por las dos reglas mencionadas.

Entonces. Una variación. 8. 21 Universidad de El Salvador. ya que las transacciones esperan a poner candados sobre los ítems de datos. Una vez que el ítem ha sido actualizado. Bases de Datos 2011 . y escribió un nuevo valor. El protocolo de bloqueo de dos fases se refina un poco con el uso del escalamiento de bloqueo para maximizar la concurrencia. La figura 13 muestra un caso de anulaciones en cascada. puede solicitar al principio candados compartidos que permitirán a otras transacciones concurrentes de solo lectura acceder a los ítems. La disminución puede tener lugar solo durante la fase de encogimiento. Aunque todas las formas del protocolo de dos fases garantizan seriabilidad. El escalamiento puede tener lugar solo durante la fase de crecimiento y tal vez requiera que la transacción espere hasta que otra transacción libere un candado compartido sobre el ítem. Después. que requiere que las transacciones mantengan todos sus candados. Cuando R se deshizo. llamada bloqueo de dos fases estricto. para a. En esta versión del bloqueo de dos fases. por lo que T tuvo que deshacerse también.Transacciones t9 t10 t11 t12 t13 t14 t15 t16 A=a*2(8) Write a(8) Desbloquear a En espera 8 En espera Garantizado el bloqueo X de a(8) a=a+10(18) Write a (18) 18 deshecha deshecha deshecha FIGURA13 Anulaciones en cascada. ocurrirá un candado moral y se necesitara el esquema de detección y recuperación ya descrito. 8. después libero su candado su candado debido a que ya no usaría a. lo que escribió. solicita que el candado compartido se escale (aumente). el valor de 4 que había escrito quedo invalido. tanto compartidos como exclusivos. Si dos transacciones esperan boquear ítem de datos ya bloqueados por otra. La transacción S leyó el valor de 4 que había escrito R. hasta que se comprometan. se invalido. Un protocolo aún más estricto es el bloqueo de dos fases riguroso. llegan a ocasionar candados mortales. su candado puede ser disminuido (convertido de uno exclusivo a uno compartido). lo que impide las anulaciones en cascada. lo que hizo que también S se deshiciera. La transacción R escribió un valor de 4 para a. La transacción T leyó el valor de 8 y calculo otro valor mas. requiere que las transacciones conserven sus candados exclusivos hasta que queden comprometidos (COMMIT). cuando la transacción esté lista para una actualización. 18. o convierta en un candado exclusivo.

.. de un registros.Transacciones NIVELES DE BLOQUEO Los candados se pueden aplicar a nivel de ítem de datos. Algunos bloquean páginas al mismo tiempo. Asi. la página A1. .. Registro (tupla) A11 Registro (tupla) A12 .. La finura o granularidad de los bloqueos se expresa por medio de una estructura jerárquica en que los nodos representan objetos de datos de diferentes tamaños. el sistema sabe sin duda que el bloqueo no puede garantizarse. Si una segunda transacción solicita un candado incompatible sobre el mismo nodo.. . la tabla A.. así como todos sus ítems de datos. Por ejemplo.. el bloqueo de la página A1 de la figura 14 bloquea los registros A11 y A12. Bases de Datos Tabla A Tabla B . si se solicita un candado exclusivo del registro A11. Por ejemplo. y la propia base de datos para ver si cualquiera de 22 Universidad de El Salvador. los nodos del nivel 1 representan las tablas. como se ilustra en la figura 14. Bases de Datos 2011 . .... antes de decidir si garantiza el candado. . el nodo raíz representa toda la base de datos. el sistema debe revisar a su padre. Siempre que un nodo este bloqueado. una solicitud de candado exclusivo sobre la pagina A1 seria denegada. los del nivel 2 son páginas de tablas. Página A1 Pagina A2 . de un grupo de archivos o de toda clase de datos. todos sus descendientes también lo estarán... los de nivel 3 son registros. Item de datos A111 Item de datos A112 FIGURA 14 Niveles de Bloqueo Aquí.. el sistema debe revisar la estructura jerárquica a partir de la raíz hasta el nodo solicitado para ver si cualquiera de sus antecesores está bloqueado.. de u archivo. . Pocos sistemas implementan candados a nivel de ítem de datos debido a lo indirecto del procedimiento.. a su abuelo.. Si la segunda transacción solicita un candado incompatible sobre cualquiera de los descendientes del nodo bloqueado. y los restantes representan ítem de datos.

lo que quiere decir que ningún bloqueo se garantiza una vez que se haya bloqueado cualquiera. y merece una atención especial. el sistema tendría que comprobar cada página de la tabla. y ningún nodo se desbloquea hasta que todos sus descendientes hayan sido desbloqueados.0 de MySQL. ya que desde la versión 3. Cuando se bloquea algún nodo. MyISAM. niega la solicitud. y definir reglas de integridad referencial. el soporte para este tipo de tablas es habilitado por default. ya que se almacenan en un sólo archivo en lugar de tres. ¿Qué pasa si una transacción solicita el bloqueo de un nodo cuando uno de sus descendientes ya ha sido bloqueado? Un ejemplo es. y deben detectarse y resolverse con los métodos ya analizados. ningún nodo se bloquea hasta que su padre queda bloqueado por un nodo de intención. y liberar bloqueos de los restantes hacia arriba. MyISAM). Para garantizar la seriabilidad con niveles de bloqueo. el sistema usa otro tipo de bloqueo llamado bloqueo de intención. con el empleo de nodos de intención hasta que se alcanza el nodo que requiere un candado compartido o exclusivo. se utiliza el protocolo de dos fases. tales como ISAM. Las tablas del tipo InnoDB están estructuradas de forma distinta que MyISAM.Transacciones ellos está bloqueado. para ver si cualquiera de ellos está bloqueado. El soporte de transacciones que provee MySQL no es algo nuevo en MySQL 5.23 se podía hacer uso de tablas InnoDB. se coloca un bloqueo de intención en todos sus antecesores. aún son posibles los candados mortales. cada registro en esas páginas. y cada conjunto de datos en esos registros. si se solicita un bloqueo de la tabla A. si algún descendiente de la tabla A (verbigracia: a la página A1) está bloqueado. InnoDB es el tipo de tabla más importante (después del tipo predeterminado. Sin embargo. la presencia de un bloqueo de intención en esta indicara que alguno de los descendientes de ese nodo ya está bloqueado. 23 Universidad de El Salvador. Bases de Datos 2011 . Transacciones en Mysql. De éstos. Los bloqueos de intención usan el modo exclusivo o compartido. Cuando encuentre que la página A1 ya ha sido bloqueada. InnoDB y BDB (Berkeley Database). El efecto de estas reglas es aplicar el bloqueo desde la raíz y hacia abajo. Así. y sus principales características son que permite trabajar con transacciones. la única diferencia es que con la llegada de la versión 4. Para reducir la búsqueda involucrada en la localización de bloqueos de los descendientes. y se hace una solicitud de bloquear la tabla A. El servidor de bases de datos MySQL soporta distintos tipos de tablas.

Un ejemplo típico de esto es una transacción bancaria. si una cantidad de dinero es transferida de la cuenta de una persona a otra. las tablas que soportan transacciones. o sentencias SQL que son agrupadas como una sola. Si disponemos de una serie de consultas SQL que deben ejecutarse en conjunto. Para este fin. Por otra parte. las transacciones pueden hacer que las consultas tarden más tiempo en ejecutarse. De hecho.Transacciones Las transacciones aportan una fiabilidad superior a las bases de datos. En efecto. son mucho más seguras y fáciles de recuperar si se produce algún fallo en el servidor. Bases de Datos 2011 . podríamos decir que las transacciones aportan una característica de "deshacer" a las aplicaciones de bases de datos. ya que las consultas se ejecutan o no en su totalidad. Por ejemplo. se requerirán por lo menos dos consultas: 24 Universidad de El Salvador. una de las principales características de las tablas del tipo InnoDB es que pueden trabajar con transacciones. como es el caso de InnoDB. con el uso de transacciones podemos tener la certeza de que nunca nos quedaremos a medio camino de su ejecución. Para asegurarnos que tenemos soporte para el tipo de tablas InnoDB podemos ejecutar la siguiente sentencia: La variable más importante es por supuesto have_innodb que tiene el valor YES.

pero debemos especificar que se trata de una tabla del tipo InnoDB (TYPE= InnoDB). 25 Universidad de El Salvador. o en su caso. Únicamente cuando se procesa un COMMIT los cambios hechos por las consultas serán permanentes. y creerá que ha realizado su pago. Si se quieren los cambios a la base de datos. Esto es aplicable a cualquier tipo de tabla. Actualizar. MySQL supone que se trata de una tabla MyISAM(en algunos casos). Estas dos consultas deben trabajar bien.Transacciones UPDATE cuentas SET balance = balance . Si sucede algún problema. completar la transacción con el uso de la sentencia COMMIT. Bases de Datos 2011 . Lo primero que tenemos que hacer es crear una tabla del tipo InnoDB e insertar algunos datos. Para crear una tabla InnoDB. sin embargo. pero cuando no se especifica nada. podemos hacer uso de la sentencia ROLLBACK para cancelar los cambios que han sido realizados por las consultas que han sido ejecutadas hasta el momento. Es aquí donde las transacciones toman un papel muy importante. UPDATE cuentas SET balance = balance + cantidad_transferida WHERE cliente = persona2. que no se ejecute ninguna de ellas. pero la segunda aún no se ha completado? La persona1 tendrá una cantidad de dinero removida de su cuenta. procedemos con el código SQL estándar CREATE TABLE. insertar o eliminar registros en la base de datos. Los pasos para usar transacciones en MySQL son: Iniciar una transacción con el uso de la sentencia BEGIN ó START TRANSACTION. En este ejemplo tan sencillo se ilustra la necesidad de que las consultas sean ejecutadas de manera conjunta. Vamos a ejecutar algunas consultas para ver como trabajan las transacciones.cantidad_transferida WHERE cliente = persona1. ¿pero que sucede si ocurre algún imprevisto y "se cae" el sistema después de que se ejecuta la primera consulta. la persona2 estará enfadada puesto que pensará que no se le ha depositado el dinero que le deben.

26 Universidad de El Salvador. Ahora veamos como usar transacciones. y los cambios realizados sobre la tabla no tendrán efecto. Si en este momento ejecutamos un ROLLBACK. nada espectacular. Bases de Datos 2011 .Transacciones De acuerdo. la transacción no será completada.

27 Universidad de El Salvador. Bases de Datos 2011 . pero haremos un COMMIT.Transacciones Ahora vamos a repetir la sentencia INSERT ejecutada anteriormente. Una vez que hacemos un COMMIT. la transacción es completada.0. y todas las sentencias SQL que han sido ejecutadas previamente afectan de manera permanente a las tablas de la base de datos. InnoDB soporta los comandos SAVEPOINT y ROLLBACK TO SAVEPOINT. Desde MySQL 5.

el antiguo se borra y se crea el nuevo. Si la transacción actual tiene un punto con el mismo nombre. (Tenga en cuenta que para un nuevo registro insertado. el bloqueo de registro se libera al deshacerse todo. .) Los puntos creados tras el punto nombrado se borran. el bloqueo no se almacena separadamente en memoria. pero InnoDB no libera los bloqueos de registro que se almacenaron en memoria tras el punto . o un ROLLBACK que no nombre ningún punto. Bases de Datos 2011 . Las modificaciones que la transacción actual hace al registro tras el punto se deshacen en el rollback. Si un comando retorna el siguiente error. El comando ROLLBACK TO SAVEPOINT deshace una transacción hasta el punto nombrado. En este caso.Transacciones El comando SAVEPOINT crea un punto dentro de una transacción con un nombre que lo identifiqué por ejemplo SAVEPOINT PUNTO. la información de bloqueo se realiza a partir del ID de transacción almacenado en el registro.A continuación se presenta el uso de estos dos comandos: 28 Universidad de El Salvador. significa que no existe ningún punto con el nombre especificado: ERROR 1305 (42000): SAVEPOINT (nombredelsavepoint) does not exist Todos los puntos de la transacción actual se borran si ejecuta un COMMIT.

para ello esta variable debe de tener el valor de 1. Transacciones Explicitas e Implicitas. pero para ello se debe de utilizar una variable denominada para ello @@autocommit. 29 Universidad de El Salvador. en la siguiente imagen se ve como se utiliza el comando ROLLBACK TO SAVEPOINT: Como se pude observar al usar el comando ROLLBACK TO SAVEPOINT y después ejecutar un select * from innotest. En mysql también se da lo que son las transacciones explicitas e implícitas.Transacciones En la imagen anterior se pude observar que se ha utilizado el comando SAVEPOINT con el identificador puntoRetorno. Las transacciones Explicitas son aquellas que se inician con el comando BEGIN y se terminan explícitamente con el comando COMMIT O ROLLBACK. Bases de Datos 2011 . se confirmó que el savepoint si funciona y que el ultimo insert que se realizó después de ver declarado el savepoint no esta presente en la consulta.

para ello esta variable debe de tener el valor de 0 y se puede utilizar de la siguiente manera: En mysql se debe de tomar aspectos importante al momento de usar las transacciones. Query OK. Query OK. pero para los comando como update y delete.Transacciones Las transacciones Implícitas son aquellas que se inician con el comando BEGIN y al utilizar COMMIT O ROLLBACK finaliza la transacción pero vuelve a iniciarse una nueva automáticamente. Empty set (0. valor double)engine=innodb. 1 row affected (0. Empty set (0.500). 1 row affected (0. Para este ejemplo utilizaremos dos conexiones para ver lo que sucede. 0 rows affected (0. pero para ello se debe de utilizar una variable denominada para ello @@autocommit. para ello usaremos como ejemplo la tabla siguiente: Mysql> create table cantidad (id int primary key not null. 0 rows affected (0. el gestor utiliza candados y lo asigna a la primera transacción que haya utilizados estas comando.00 sec) Mysql > begin .00 sec) mysql> insert into cantidad value(2.00 sec) Mysql > begin .00 sec) mysql> insert into cantidad value(1. Bases de Datos 2011 .100). Query OK. Query OK.00 sec) Conexión 2 mysql> select * from cantidad.00 sec) 30 Universidad de El Salvador. en el caso de que las transacciones solo sean unos simple insert el gestor de bases de datos no utiliza candados. empezaremos con unos simple insert: Conexión 1 mysql> select * from cantidad.

0 rows affected (0. Query OK.00 sec) 31 Universidad de El Salvador.00 sec) mysql> update cantidad set valor=450 where id=2. Query OK. try restarting transaction Mysql>rollback. Query OK.00 sec) mysql> update cantidad set valor=1000 where id=2. actualizaremos de la conexión dos la tupla que tiene el id 2 y veremos como para la conexión dos queda con un candado: Conexión 1 Mysql > begin . +----+-------+ | id | valor | +----+-------+ | 1 | 500 | +----+-------+ 1 row in set (0. 0 rows affected (0. 0 rows affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> select * from cantidad.Transacciones mysql> select * from cantidad. +----+-------+ | id | valor | +----+-------+ | 1 | 500 | | 2 | 1000 | +----+-------+ 2 rows in set (0. 1 row affected (0. Query OK.01 sec) mysql> select * from cantidad. 0 rows affected (0. +----+-------+ | id | valor | +----+-------+ | 1 | 500 | | 2 | 100 | +----+-------+ 2 rows in set (0. +----+-------+ | id | valor | +----+-------+ | 2 | 100 | +----+-------+ 1 row in set (0. Query OK. Query OK. ERROR 1205 (HY000): Lock wait timeout exceeded.01 sec) mysql> commit.01 sec) El resultado final haciendo un select independiente de la conexión seria el siguiente: mysql> select * from cantidad.00 sec) mysql> commit. Bases de Datos 2011 .00 sec) Conexión 2 Mysql > begin . 0 rows affected (0.00 sec) Retomando los mismos datos que acabamos de insertar en una conexión.

mysql> update cantidad set valor=(@vl+100) where id=2. Query OK.01 sec) 32 Universidad de El Salvador.01 sec) El resultado final haciendo un update independiente de la conexión seria el siguiente: mysql> select * from cantidad. 0 rows affected (0.00 sec) Ese mismo tipo de bloque sucede cuando se utiliza la sentencia delete. para ello utilizaremos el valor que tiene el id 2 de la tabla cantidad y trataremos de actualizarla. +------------+ +------------+ | @vl:=valor | | @vl:=valor | +------------+ +------------+ | 1000 | | 1000 | +------------+ +------------+ 1 row in set (0. . Query OK. +----+-------+ | id | valor | +----+-------+ . A continuación se mostrara como seria el problema de La actualización perdida (jack y jill) con transacciones en mysql. where id=2.00 sec) 1 row in set (0. Query OK. . 0 rows affected (0. 0 rows affected (0. Conexión 1 Mysql > begin . 1 row affected (0. +----+-------+ | id | valor | +----+-------+ | 1 | 500 | | 2 | 1000 | +----+-------+ 2 rows in set (0. . . 0 rows affected (0. Query OK. 0 rows affected (0.00 sec) mysql> update cantidad set valor=(@vl-50) where id=2. Bases de Datos 2011 mysql> select * from cantidad. Query OK. Query OK. Query OK. 1 row affected (0.Transacciones mysql> commit.00 sec) mysql> select @vl:=valor from cantidad mysql> select @vl:=valor from cantidad where id=2.00 sec) .01 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> commit.01 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> commit.00 sec) Conexión 2 Mysql > begin .

InnoDB ofrece los cuatro niveles de aislamiento de transacciones descriptos por el estándar SQL. InnoDB también puede bloquear el “vacío” que precede a un registro de índice para bloquear inserciones de otros usuarios inmediatamente antes del registro de índice. En otro caso. las lecturas no son consistentes al usar este nivel de aislamiento. el tipo de tabla innodb nos proporciona los siguientes aspectos de asilamiento. no el espacio que lo precede.. Los niveles de aislamiento de transacciones globales y de sesión pueden consultarse con estas sentencias: SELECT @@global. Esto significa que. Por lo tanto. Bloquear una posición vacía es establecer un bloqueo que actúa solamente sobre el vacío anterior a un registro de índice. Todas las sentencias SELECT . A continuación una descripción detallada de cada nivel de aislamiento en InnoDB:  READ UNCOMMITTED Las sentencias SELECT son ejecutadas sin realizar bloqueos. Esto también se denomina “lectura sucia” (dirty read). no los espacios vacíos que los preceden.00 sec) mysql> select * from cantidad. este nivel de aislamiento funciona igual que READ COMMITTED. además de registros de índice. READ COMMITTED Similar en parte al mismo nivel de aislamiento de Oracle. el nivel predeterminado en InnoDB es REPEATABLE READ. por lo tanto se permite la libre inserción de nuevos registros junto a los bloqueados. En MySQL 5. InnoDB emplea bloqueo de clave siguiente (next-key).0.. Las sentencias UPDATE and DELETE que empleen un índice único con una condición de búsqueda única bloquean solamente el registro de índice hallado. En los términos de los niveles de aislamiento de transacciones SQL:1992..Transacciones | 1 | 500 | | 2 | 950 | +----+-------+ 2 rows in set (0. +----+-------+ | id | valor | +----+-------+ | 1 | 500 | | 2 | 1100 | +----+-------+ 2 rows in set (0. Un bloqueo de clave siguiente hace referencia a bloquear un registro de índice y la posición vacía antes de él.00 sec) Como evitar estos problemas. SELECT @@tx_isolation. Bases de Datos 2011  . pero podría usarse una versión anterior de un registro. FOR UPDATE y SELECT .. LOCK IN SHARE MODE bloquean solamente los registros de índice.tx_isolation. En las 33 Universidad de El Salvador. En el bloqueo a nivel de fila.

Query OK. mysql> update cantidad set valor=(@vl-50) . Rows matched: 1 Changed: 1 Warnings: 0 mysql> commit. Conexión 1 Mysql > begin . LOCK IN SHARE MODE. .. y bloqueando las nuevas inserciones por parte de otros usuarios. Esto es necesario debido a que las “filas fantasma” deben ser bloqueadas para que funcionen la replicación y recuperación en MySQL. Las sentencias SELECT . pero todas las sentencias SELECT son convertidas implícitamente a SELECT . y DELETE que utilicen un índice único con una condición de búsqueda única. estas operaciones emplean bloqueo de clave siguiente (next-key). 0 rows affected (0. SELECT . LOCK IN SHARE MODE. SERIALIZABLE Este nivel es similar a REPEATABLE READ. for update. where id=2.. FOR UPDATE. Query OK.. REPEATABLE READ Este es el nivel de aislamiento predeterminado de InnoDB. bloquean solamente el registro de índice hallado. ERROR 1205 (HY000): Lock wait timeout +------------+ exceded. para ello utilizaremos el comando select…. 34 .Transacciones sentencias UPDATE y DELETE que actúan sobre rangos de registros. try restarting transaction | @vl:=valor | +------------+ En este momento la primera conexión ha | 1100 | utilizando un candado y se liberara +------------+ cuando esta termina la transacción con un 1 row in set (0. InnoDB debe bloquear los espacios vacíos y bloquear las inserciones de otros usuarios en los espacios vacíos que hay dentro del rango.01 sec) commit o un rollback. Query OK. bloqueando el rango de índice cubierto por la operación incluyendo los espacios vacíos. Resolviendo el problema de la actualización perdida (jack y jill).00 sec) Universidad de El Salvador. 1 row affected (0. UPDATE.. where id=2 for update.01 sec) .. 0 rows affected (0. 0 rows affected (0.00 sec) Conexión 2 Mysql > begin .00 sec) mysql> select @vl:=valor from cantidad mysql> select @vl:=valor from cantidad where id=2 for update. Query OK.   Hay que tener mucho cuidado con el uso de select … lock in share mode. no el espacio vacío que lo precede. Con otras condiciones de búsqueda. porque si varias transacciones la utilizan podría generarse un candado mortal. Bases de Datos 2011 mysql> select @vl:=valor from cantidad where id=2 for update..

Transacciones +------------+ | @vl:=valor | +------------+ | 1050 | +------------+ 1 row in set (0. 0 rows affected (0. Bases de Datos 2011 . +----+-------+ | id | valor | +----+-------+ | 1 | 500 | | 2 | 1150 | +----+-------+ 2 rows in set (0. Query OK.00 sec) 35 Universidad de El Salvador.00 sec) mysql> select * from cantidad. 1 row affected (0.01 sec) mysql> update cantidad set valor=(@vl+100) where id=2. Query OK. +----+-------+ | id | valor | +----+-------+ | 1 | 500 | | 2 | 1050 | +----+-------+ 2 rows in set (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> commit.00 sec) mysql> select * from cantidad.

Sign up to vote on this title
UsefulNot useful