10.07.2015 Views

Concurrencia

Concurrencia

Concurrencia

SHOW MORE
SHOW LESS
  • No tags were found...

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Jose Manuel PerezDaniel FutrilléProf. Ana Aguilera


Una transacción es una ejecución de un programa de usuario, visto por elDBMS como una serie de operaciones lecturas y escrituras, la cual accede a labase de datos que es compartida por varios usuarios en forma simultánea. Esuna colección de acciones que hacen transformaciones de los estados de unsistema preservando la consistencia del mismo.Una base de datos está en un estado consistente si obedece todas lasrestricciones de integridad definidas sobre ella. Los cambios de estado ocurrendebido a actualizaciones, inserciones, y supresiones de información. Porsupuesto, se quiere asegurar que la base de datos nunca entra en un estado deinconsistencia. Sin embargo, durante la ejecución de una transacción, la basede datos puede estar temporalmente en un estado inconsistente. El puntoimportante aquí es asegurar que la base de datos regresa a un estadoconsistente al fin de la ejecución de una transacción.


La Base deDatos enestadoconsistenteLa Base de Datostemporalmente en unestado inconsistentedurante la ejecución de latransacciónLa Base deDatos enestadoconsistenteInicio de TransacciónT1Ejecución de laTransacción T1Fin de Transacción T1Para fines de recuperación el sistema necesita mantenerse al tanto de cuandola transacción se inicia, termina y se confirma o aborta, así el gestor derecuperación se mantiene al tanto de las siguientes operaciones:


Operaciones y Cuerpo de una Transacción:Begin transaction : inicio de la transacciónRead a : lectura del objeto aWrite a : escritura del objeto aRollback : anulación de la transacciónCommit : fin de la transacciónBegin transaction TO1O2...OnCommit TOi e conjunto deoperaciones


Propiedades de las transacciones:• Atomicidad: Se refiere al hecho de que una transacción se trata como unaunidad de operación. Por lo tanto, o todas las acciones de la transacción serealizan o ninguna de ellas se lleva a cabo. La atomicidad requiere que si unatransacción se interrumpe por una falla, sus resultados parciales deben serdeshechos. La actividad referente a preservar la atomicidad de transaccionesen presencia de abortos debido a errores de entrada, sobrecarga del sistemao interbloqueos se le llama recuperación de transacciones. La actividad deasegurar la atomicidad en presencia de caídas del sistema se le llamarecuperación de caídas.• Consistencia: La consistencia de una transacción es simplemente sucorrectitud. En otras palabras, una transacción es un programa correcto quelleva la base de datos de un estado consistente a otro con la mismacaracterística. Debido a esto, las transacciones no violan las restricciones deintegridad de una base de datos.


Propiedades de las transacciones:• Aislamiento: Una transacción en ejecución no puede revelar sus resultados aotras transacciones concurrentes antes de su commit. Más aún, si variastransacciones se ejecutan concurrentemente, los resultados deben ser losmismos que si ellas se hubieran ejecutado de manera secuencial(seriabilidad).• Durabilidad: Es la propiedad de las transacciones que asegura que una vezque una transacción hace su commit, sus resultados son permanentes y nopueden ser borrados de la base de datos. Por lo tanto, los DBMS aseguranque los resultados de una transacción sobrevivirán a fallas del sistema. Estapropiedad motiva el aspecto de recuperación de bases de datos, el cual tratasobre como recuperar la base de datos a un estado consistente en dondetodas las acciones que han hecho un commit queden reflejadas.


Ejemplo: transferencia de fondos1. read(A)2. A := A – 503. write(A)4. read(B)5. B := B + 506. write(B)Transacción paratransferir $50 de lacuenta A a la cuenta B• Consistencia: la suma de A y B no debecambiar por la ejecución de la transacción• Atomicidad: si la transacción falla entre lospasos 3 y 6, el sistema debe asegurar que loscambios no se reflejen en la BD• Aislamiento: si entre los pasos 3 y 6 se lepermite a otra transacción acceder a los datosparcialmente modificados, verá un estadoinconsistente de la BD• Durabilidad: una vez que el usuario ha sidonotificado que la transacción se realizó, loscambios deben persistir a pesar de fallas


Condiciones de terminación de una transacción:Una transacción siempre termina, aun en la presencia de fallas. Si unatransacción termina de manera exitosa se dice que la transacción hace uncommit. Si la transacción se detiene sin terminar su tarea, se dice que latransacción aborta. Cuando la transacción es abortada, su ejecución esdetenida y todas sus acciones ejecutadas hasta el momento son deshechas(undone) regresando a la base de datos al estado antes de su ejecución. A estaoperación también se le conoce como rollback.


Caracterización de transacciones:Las acciones de lectura y escritura se utilizan como base para caracterizar a lastransacciones. Los elementos de datos que lee una transacción se dice queconstituyen el conjunto de lectura (RS). Similarmente, los elementos dedatos que una transacción escribe se les denomina el conjunto de escritura(WS). Note que los conjuntos de lectura y escritura no tienen que sernecesariamente disjuntos. La unión de ambos conjuntos se le conoce como elconjunto base de la transacción (BS = RS U WS).Ejemplo: Los conjuntos de lectura y escritura de la siguiente transacción:RS[Reservación] = { FLIGHT.STSOLD, FLIGHT.CAP }WS[Reservación] = { FLIGHT.STSOLD, FC.FNO, FC.DATE, FC.NAME,FC.SPECIAL }


Transacciones y Planificaciones (Schedules):Hasta ahora conocemos que una transacción es vista por el DBMS como unaserie, o lista, de acciones las cuales ejecutan operaciones de lectura yescritura en elementos de la Base de Datos. También sabemos que unatransacción debe especificar su acción de finalización como commit (Finalizóexitosamente) o abort (finalizó pero deshizo todas las acciones llevadas acabo).Ahora, una planificación, es una lista de acciones (lecturas, escrituras, abortos ocommit) de un conjunto de transacciones, y el orden que el cual dos accionesde una transacción T aparecen en una Planificación debe ser el mismo ordenen el cual aparecen en T. En otras palabras una Planificación representa unasecuencia de ejecución actual o potencial el cual describe las acciones de lastransacciones así como son vistas por el DBMS.


Ejecución concurrente de transaccionesConociendo el concepto de planificación, ahora se puede describirejecuciones entrelazadas o interleaved de transacciones.El DBMS entrelaza las acciones de diferentes transacciones para mejor elrendimiento, en términos de incrementar el promedio de transaccionescompletadas en un determinado tiempo o mejorar los tiempos de respuestasde las transacciones cortas.


Motivos para ejecución concurrente:La Planificación mostrada en la siguiente figura muestra una ejecuciónentrelazada de dos transacciones.Asegurar el aislamiento de lastransacciones mientras se permitela ejecución concurrente es difícil,pero es necesario, hay que mejorarel rendimiento.


Seriabilidad:Cualquier ejecución de un conjunto de transacciones es correcta si es librede interferencias.Una planificación Serializable es una equivalencia de alguna de lasejecuciones seriales de las transacciones. Si cada transacción preservaconsistencia, cada planificación serializable preserva consistencia.


Anomalías que surgen con la ejecución entrelazadasLa ejecución entrelazadas de transacciones sin control puederesultar en una base de datos inconsistente.Problemas de:– Pérdida de la actualización:Diferentes ejecuciones entrelazadas pueden producirvalores finales diferentes.– Lectura inconsistente:Existen ejecuciones entrelazadas que violan RI.– Lectura irreproducible:Existen ejecuciones entrelazadas donde el valordesplegado no es el mismo.-Sobreescribiendo datos inconsistente-Existe una transacción que sobreescribe un valor, el cual había sido modificadopor otra transacción mientras esta estaba corriendo.


Conflictos de WR:T1: R(A), W(A), R(B), W(B), AbortT2: R(A), W(A), C


Conflictos de WR:T1: R(A), R(A), W(A), CT2: R(A), W(A), CConflictos de WW:T1: W(A), W(B), CT2: W(A), W(B), C


Planificación Invocando a transacciones AbortadasUna transacción siempre termina, aun en lapresencia de fallas. Si una transacción termina demanera exitosa se dice que la transacción hace uncompromiso. Si la transacción se detiene sinterminar su tarea, se dice que la transacciónaborta.Cuando la transacción es abortada, puede ser pordistintas razones relacionadas con la naturaleza dela transacción misma, o por conflicto con otrastransacciones o por fallo de un proceso ocomputador, entonces su ejecución es detenida ytodas las acciones ejecutadas hasta el momentoson deshechas regresando a la base de datos alestado antes de su ejecución. A esta operacióntambién se la conoce como rollback.


Control de <strong>Concurrencia</strong> Basado en Lock:En los algoritmos basados en candados, las transacciones indican sus intencionessolicitando candados al despachador (llamado el administrador de candados) Loscandados son de lectura , también llamados compartidos, o de escritura , tambiénllamados exclusivos.En sistemas basados en candados, el despachador es un administrador decandados . El administrador de transacciones le pasa al administrador decandados la operación sobre la base de datos (lectura o escritura) e informaciónasociada, como por ejemplo el elemento de datos que es accedido y elidentificador de la transacción que está enviando la operación a la base de datos.


Tipos de Transacciones:Las transacciones pueden pertenecer a varias clases. Las transacciones puedenser agrupadas a lo largo de las siguientes dimensiones:Áreas de aplicación. En primer lugar, las transacciones se pueden ejecutar enaplicaciones no distribuidas. Las transacciones que operan en datosdistribuidos se les conoce como transacciones distribuidas.Tiempo de duración. Tomando en cuenta el tiempo que transcurre desde que seinicia una transacción hasta que se realiza un commit o se aborta, lastransacciones pueden ser de tipo batch o en línea.Estructura. Considerando la estructura que puede tener una transacción seexaminan dos aspectos: si una transacción puede contener a su vezsubtransacciones o el orden de las acciones de lectura y escritura dentro deuna transacción


Estructuras de las Transacciones:Las transacciones planas consisten de una secuencia de operaciones primitivasencerradas entre las palabras clave begin y end. Por ejemplo,Begin_transaction Reservación. . .end.En las transacciones anidadas las operaciones de una transacción pueden ser asímismo transacciones. Por ejemplo,Begin_transaction Reservación. . .Begin_transaction Vuelo. . .end. {Vuelo}. . .Begin_transaction Hotel. . .end.. . .end.


Aspectos relacionados al procesamiento de transacciones:• Modelo de estructura de transacciones: considerar si las transacciones sonplanas o pueden estar anidadas.• Consistencia de la base de datos interna: Los algoritmos de control dedatos semántico tienen que satisfacer siempre las restricciones de integridadcuando una transacción pretende hacer un commit.• Algoritmos de control de concurrencia: Los algoritmos de control deconcurrencia deben sincronizar la ejecución de transacciones concurrentesbajo el criterio de correctitud. La consistencia entre transacciones se garantizamediante el aislamiento de las mismas.• Protocolos de control de réplicas: El control de réplicas se refiere a cómogarantizar la consistencia mutua de datos replicados. Por ejemplo se puedeseguir la estrategia read-one-write-all (ROWA).


Conceptos relacionados con el control de concurrencia:Planificación serial: recordamos elconcepto antes visto; para cada transacciónT participando en el Planificación, todas lasoperaciones de T se ejecutanconsecutivamente en la Planificación; sino, Tes no serial.Planificaciones Equivalentes: Para quedos Planificaciones sean equivalentes, lasoperaciones aplicadas a cada dato afectadopor las planificaciones deben ser aplicadasen ambas planificaciones en el mismo ordenPlanificación serializable: equivalente aalguna Planificación serialT1read (A)A := A-50write (A)read (B)B := B+50write (B)CommitT2read (A);temp := A * 0.1A := A – tempwrite (A)read (B)B:=B+tempwrite (B)CommitPlan Serializable


Conceptos relacionados con el control de concurrencia:Serializabilidad:Un plan serializable implica que el plan es correcto• Deja la base de datos en un estado consistente• El intercalamiento es apropiado y resultará en un estado como si lastransacciones fueran ejecutadas secuencialmente, pero será eficiente debido a laejecución concurrente.La serializabilidad es difícil de verificar• El intercalamiento de las operaciones ocurre en el sistema operativo a través deun planificador• Difícil determinar de antemano como las operaciones serán intercaladasEnfoque práctico:Protocolos asegurando la serializabilidad a través del uso de Candados (locks)


Propósito del Control de <strong>Concurrencia</strong>:En general, reforzar el aislamiento (a través de la exclusión mutua) entretransacciones conflictivas.En particular, evitar los problemas de:• Actualización perdida• Actualización temporal• Suma incorrecta


Problema de la Actualización Perdida:Ocurre cuando dos transacciones que acceden los mismos datos tienen susoperaciones intercaladas de forma que hacen que el valor de un dato seaincorrecto.T1read_item (X)X := X-Nwrite_item (X)read_item (Y)Y:= Y+Nwrite_item (Y)CommitT2read_item (X)X := X+Mwrite_item (X)CommitX tiene un valor incorrectoporque la actualización de T1 sepierde


Problema de la de la actualización temporal:Ocurre cuando una transacción actualiza un dato y después falla. El datoactualizado es accedido por otra transacción antes de cambiar su valor aloriginal.T1read_item (X)X := X-Nwrite_item (X)read_item (Y)AbortT2read_item (X)X := X+Mwrite_item (X)CommitT1 falla y debe regresar el valormodificado de X al original; T2leyó temporalmente el valorincorrecto de X.


Problema de la suma incorrecta:Si una transacción está calculando una función matemática sobre un conjuntode tuplas mientras que otras transacciones están actualizándolas, elresultado puede ser incorrecto.T1read_item (X)X := X-Nwrite_item (X)read_item(Y)Y := Y+Nwrite_item(Y)CommitT3sum :=0read_item(A)sum := sum+Aread_item(X)sum:=sum+Xread_item(Y)sum :=sum+YCommitT3 lee X después de sustraer N ylee Y antes de sumar N: elresultado es incorrecto


Protocolos basados en candados (Locks):Es un conjunto de reglas seguidas por todas las transacciones para solicitar yliberar candados. Un candado es un mecanismo de control de accesoconcurrente a un datoLos datos pueden tener candados en dos modos:• Modo exclusivo (X). El dato puede ser leído y escrito. Un candado en estemodo se solicita con la instrucción lock-X• Modo compartido (S). El dato solo puede ser leído. Un candado en estemodo se solicita con la instrucción lock-S.Las transacciones indican sus intenciones solicitando candados al despachador(llamado el administrador de candados). La transacción puede procedersolo después de que una solicitud es otorgada.


Protocolos basados en candados:Como se aprecia en la tabla siguiente, los candados de lectura presentanconflictos con los candados de escritura, dado que las operaciones delectura y escritura son incompatibles.• Un candado es otorgado si el candadosolicitado es compatible con otros candadospreviamente otorgados.• Se pueden tener varios candadoscompartidos sobre un dato, pero sólo uncandado exclusivo.El poner candados no es suficientepara garantizar serializabilidad• Si un candado no puede ser concedido, latransacción que lo solicita debe esperar aque todos los candados incompatibles seanliberados.


Protocolo de candado en dos fases (2PL):Asegura planificaciones serializables.Fase 1: Crecimiento• Una transacción puede solicitar/obtener candados• Una transacción no puede liberar candadosFase 2: reducción• Una transacción puede liberar candados• Una transacción no puede obtener candadosEn los candados de dos fases una transacción le pone un candado a un objetoantes de usarlo. Cuando un objeto es bloqueado con un candado por otratransacción, la transacción solicitante debe esperar. Cuando unatransacción libera un candado, ya no puede solicitar más candados.


Protocolo de candado en dos fases (2PL):Una transacción que utiliza candados de dos fases se comporta como en lasiguiente figura. En la primera fase solicita y adquiere todos los candadossobre los elementos que va a utilizar y en la segunda fase libera loscandados obtenidos uno por uno.


Protocolo de candado en dos fases (2PL):La importancia de los candados de dos fases es que se ha demostrado demanera teórica que todos los planificadores generados por algoritmos decontrol de concurrencia que obedecen a los candados de dos fases sonserializables.Abortos en Cascada: Puede suceder si una transacción aborta después deliberar un candado, otras transacciones que hayan accedido el mismoelemento de datos aborten también.Para evitar lo anterior, los despachadores para candados de dos fasesimplementan lo que se conoce como los candados estrictos de dos fasesen los cuales se liberan todos los candados juntos cuando la transaccióntermina (con commit o aborta).Ver la siguiente figura.


Protocolo de candado en dos fases (2PL):


Problemas de los protocolos basados en candados: abrazo mortal:Abrazo mortal: dos transacciones esperan mutuamente a que la otra libere uncandado.Prevención: una transacción pone un candado a todos los datos a los que serefiere antes de comenzar su ejecución.Evitar: si una transacción intenta crear un ciclo, entonces se echa para atrás(roll back) esa transacción.


Problemas de los protocolos basados en candados: inanición:Ocurre cuando una transacción en particular consistentemente espera o esreinicializada y nunca tiene la posibilidad de seguir adelante.Esta limitación es característica de todos los mecanismos de planificaciónbasados en prioridades (estampillas de tiempo).


Tecnicas de cerraduras EspecializadasLecturas fantasmaUna transacción vuelve a ejecutar una consulta, devolviendo un conjunto de filasque satisfacen una condición de búsqueda y encuentra que otras filas quesatisfacen la condición que han sido insertadas por otra transacción cursada.


Control de <strong>Concurrencia</strong> sin lockingControl de concurrencia optimistaLos algoritmos de control de concurrencia discutidos antes son por naturalezapesimistas. En otras palabras, ellos asumen que los conflictos entretransacciones son muy frecuentes y no permiten el acceso a un dato si existe unatransacción conflictiva que acceda al mismo dato. Así, la ejecución de cualquieroperación de una transacción sigue la secuencia de fases: validación (V), lectura(R), cómputo (C) y escritura (W). Los algoritmos optimistas, por otra parte,retrasan la fase de validación justo antes de la fase de escritura. De esta manera,una operación sometida a un despachador optimista nunca es retrasada.


• Database Management, Ramakrishnan Gehrke• Sistema de bases de datos, Elmasri Navathe• http://www.utm.mx/~caff/perso/index.html• http://www.cs.princeton.edu/courses/archive/spr00/cs425/slides/• https://dpt-info.u-strasbg.fr/doc/oracle/server.102/b14220/transact.htm• www.cs.ust.hk/~dimitris• codex.cs.yale.edu/avi/db-book• http://www.cs.cinvestav.mx/SC/prof_personal/adiaz/Disdb/Cap_5.html• http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/MonogSO/TRANS02.htm• http://es.tldp.org/Postgresql-es/web/navegable/user/x3589.html

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!