Serializabilidad

En control de concurrencia de bases de datos, procesamiento de transacciones (administración de transacciones) y varios transaccional aplicaciones (por ejemplo, memoria transaccional y software de memoria transaccional), ambos centralizados y distribuido, una transacción horario es serializable Si su resultado (por ejemplo, el estado de base de datos resultante) es igual al resultado de sus transacciones realizadas en serie, es decir, secuencialmente sin superposición en el tiempo. Las transacciones normalmente se ejecutan concurrentemente (que se solapan), ya que esta es la manera más eficiente. Serializabilidad es el criterio de mayor exactitud para las ejecuciones de transacciones simultáneas. Es considerado el más alto nivel de aislamiento entre transacciones, y desempeña un papel esencial en control de concurrencia. Como tal se apoya en todos los sistemas de base de datos de propósito general. Fuerte estricto bloqueo de dos fases (SS2PL) es un mecanismo serializabilidad popular utilizado en la mayoría de los sistemas de base de datos (en varias variantes) desde sus inicios en la década de 1970.

Teoría serializabilidad proporciona el marco formal para razonar sobre y analizar serializabilidad y sus técnicas. Aunque es matemática en la naturaleza, sus fundamentos son informalmente (sin notación matemática) introducidos por debajo.

Transacciones de bases de datos

Artículo principal: Transacciones de bases de datos

Para esta discusión un transacciones de bases de datos es un específico previsto ejecutar (con parámetros específicos, por ejemplo, con la identificación de la transacción, por lo menos) de un programa informático (o programas) que tiene acceso a una base de datos (o bases de datos). Un programa está escrito con la suposición de que se está ejecutando en aislamiento desde otros programas en ejecución, es decir, cuando se ejecuta, sus datos de acceso (después el acceso) no se cambian por otros programas en ejecución. Sin esta hipótesis los resultados de la transacción son impredecibles y pueden equivocarse. La misma transacción puede ejecutarse en diferentes situaciones, por ejemplo, en diferentes tiempos y lugares, en paralelo con diferentes programas. A vivir transacción (es decir, existe en un entorno informático con ya asignados los recursos computacionales; distinguir un solicitud de transacciónesperando a que los recursos de ejecución) puede estar en uno de los tres Estados o fases:

1. Corriendo -Su programa (s) es (son) ejecutando.
2. Listo -Ejecución de su programa ha terminado, y está esperando a ser Terminó (completado).
3. Terminó (o Completado)-Es Comprometido o Abortada (restaurados), dependiendo de si la ejecución se considera un éxito o no, respectivamente. Cuando se comete, todos sus recuperable (es decir, con los Estados que pueden ser controlados para este propósito), durable recursos (típicamente datos de base de datos) se ponen en su final Estados, después de correr. Cuando abortó, todos sus recursos recuperables se vuelvan a colocar su inicial los Estados, que antes de correr.

Una falla en el entorno informático de transacción antes de terminar normalmente se traduce en su interrupción. Sin embargo, una transacción puede ser abortada también por otros motivos (por ejemplo, véase infra).

Al ser terminado (completa), se liberan recursos informáticos asignados de la transacción y la transacción desaparece del entorno informático. Sin embargo, los efectos de una transacción comprometida permanecen en la base de datos, mientras que los efectos de una transacción (restaurados) abortado desaparecen de la base de datos. El concepto de transacción atómica (semántica "todo o nada") fue diseñada para lograr exactamente este comportamiento, con el fin de controlar la corrección en sistemas complejos defectuosos.

Corrección

Corrección - serializabilidad

Serializabilidad es una propiedad de una transacción horario (historia). Se relaciona con la aislamiento propiedad de un transacciones de bases de datos.

Serializabilidad de un programa significa equivalencia (en el resultado, el estado de la base de datos, valores de datos) a un serial schedule (es decir, alternativamente con ninguna superposición de transacción en el tiempo) con las mismas transacciones. Es el principal criterio para la corrección del calendario de transacciones concurrentes y así apoyado en todos los sistemas de base de datos de propósito general.

El fundamento serializabilidad es el siguiente:

Si cada transacción es correcto por sí mismo, es decir, cumple con ciertas condiciones de integridad, entonces un programa que comprende cualquier serial ejecución de estas operaciones es correcta (sus transacciones aún cumplen sus condiciones): "Serial" significa que las transacciones no se solapan en el tiempo y no pueden interferir con cada otro, es decir, completa aislamiento entre ellos existe. Cualquier orden de las transacciones es legítimo, si no las dependencias entre ellos existen, que se asume (véase el comentario a continuación). Como resultado, un programa que comprende cualquier ejecución (no necesariamente serial) que es equivalente (en su resultado) para la ejecución de cualquier serie de estas transacciones, es correcta.

Los horarios que no son serializables son propensos a generar resultados erróneos. Ejemplos bien conocidos son con las transacciones de débito y de crédito cuentas con dinero: si los horarios relacionados no son serializables, entonces la suma total de dinero no puede ser preservada. Dinero podría desaparecer o ser generado de la nada. Esto y las violaciones de posiblemente necesitaban otro invariante preservación es causados por una transacción de la escritura y "pisar" y borrar lo que ha sido escrito por otra transacción antes de que se ha convertido en permanente en la base de datos. No sucede si se mantiene la serializabilidad.

Si una aplicación solicita un orden específico entre algunas transacciones, entonces se aplica independientemente de los mecanismos subyacentes serializabilidad. Estos mecanismos son típicamente indiferentes a ningún orden específico y generan algunos impredecible orden parcial es típicamente compatible con múltiples órdenes serial de estas transacciones. Esta orden parcial resulta de las órdenes de programación de operaciones de acceso a datos de transacciones concurrentes, que dependen de muchos factores.

Es una característica importante de una transacción de base de datos atomicidad, que significa que él tampoco se compromete, es decir, los resultados de sus operaciones en vigor en la base de datos, o interrupciones (restaurados), resultados de sus operaciones no tienen ningún efecto sobre la base de datos ("all or nothing" semántica de la transacción). En todos los sistemas reales de transacciones pueden abortar por muchas razones y serializabilidad por sí sola no es suficiente para la corrección. Los horarios también deben de tener para el capacidad de recuperación (de interrupción) propiedad. Capacidad de recuperación significa que cometieron las transacciones no ha leído los datos escritos por transacciones abortadas (cuyos efectos no existen en los Estados resultantes de la base de datos). Mientras serializabilidad actualmente está comprometida a propósito en muchas aplicaciones para un mejor rendimiento (sólo en casos cuando la corrección de la aplicación no está dañada), comprometiendo la capacidad de recuperación rápidamente violaría la integridad de la base de datos, así como de los resultados de las transacciones externas a la base de datos. Un calendario con la propiedad de recuperación (un recuperable horario) "se recupera" de las interrupciones por sí mismo, es decir, las interrupciones no daña la integridad de sus transacciones confirmadas y base de datos resultante. Esto es falso sin capacidad de recuperación, donde las violaciones de la integridad probable (resultante datos incorrectos) necesitan acciones especiales, generalmente manuales, correctivas en la base de datos.

Implementación de recuperación en su forma general puede resultar en interrupciones en cascada:: Anular una transacción puede resultar en la necesidad de abortar una segunda operación y luego un tercero y así sucesivamente. Esto se traduce en una pérdida de ya parcialmente ejecutado transacciones y también puede resultar en una reducción del rendimiento. Evitar interrupciones en cascada (ACA, o Cascadelessness) es un caso especial de recuperación que impide exactamente tal fenómeno. A menudo en la práctica se utiliza un caso especial de ACA: Rigor. Rigor permite una recuperación de base de datos eficiente de fracaso.

Tenga en cuenta que el capacidad de recuperación propiedad es necesaria incluso si ninguna falla y ninguna base de datos recuperación de fracaso es necesario. Más bien es necesario controlar correctamente automáticamente las interrupciones, que pueden estar relacionadas a la falta de base de datos y recuperación de fallas.

Serializabilidad relajante

En muchas aplicaciones, a diferencia de las finanzas, absoluta corrección no es necesaria. Por ejemplo, al recuperar una lista de productos según la especificación, en la mayoría de los casos no importa mucho si un producto, cuyos datos fueron actualizado hace poco tiempo no aparece en la lista, incluso si cumple con la especificación. Normalmente aparecerá en una lista cuando intentó de nuevo poco tiempo después. Bases de datos comerciales proporcionan control de simultaneidad con toda una gama de niveles de aislamiento ¿Cuáles son en realidad violaciones serializabilidad (controlados) con el fin de lograr un mayor rendimiento. Un rendimiento más alto significa mejor tasa de ejecución de la transacción y menor tiempo de respuesta promedio de transacción (duración de la transacción). Aislamiento de instantánea es un ejemplo de un popular, ampliamente utilizado serializabilidad relajado eficiente método con muchas características de serializabilidad completo, pero todavía falta algunos y no aptos en muchas situaciones.

Otra razón común hoy en día para serializabilidad distribuido relajación (véase abajo) es el requisito de disponibilidad de de Internet productos y servicios. Este requisito es típicamente contestada por datos a gran escala replicación. La solución sencilla para la sincronización de las actualizaciones de las réplicas de un mismo objeto de base de datos está incluyendo todas estas actualizaciones en un solo atómico transacciones distribuidas. Sin embargo, con muchas réplicas tan una transacción es muy grande y puede abarcar varias ordenadores y redes que algunos de ellos suelen ser de carácter. Por lo tanto tal una transacción es probable que terminan con abortar y perder su propósito. Por lo tanto Replicación optimista (Replicación perezosa) es utilizada a menudo (por ejemplo, en muchos productos y servicios por Google, Amazonas, Yahooe igualmente), mientras que serializabilidad es relajado y comprometido para consistencia eventual. En este caso, relajación se realiza otra vez sólo para aplicaciones que no se esperan que sea perjudicado por esta técnica.

Clases de horarios definidos por serializabilidad relajado propiedades contienen la clase serializabilidad o son incomparables con él.

Serializabilidad vista y conflicto

Los mecanismos que hacen cumplir serializabilidad deben ejecutar en tiempo real, o casi en tiempo real, mientras que las transacciones se ejecutan en altas tasas. Para cumplir con este requisito especial de casos de serializabilidad, condiciones suficientes para serializabilidad que pueden aplicarse con eficacia, se utilizan.

Existen dos tipos principales de serializabilidad: vista-serializabilidad, y conflicto-serializabilidad. Vista-serializabilidad coincide con la definición general de serializabilidad dada anteriormente. Conflicto-serializabilidad es un caso especial amplio, es decir, cualquier programa que es serializable conflicto es también vista serializable, pero no necesariamente lo contrario. Conflicto-serializabilidad es ampliamente utilizado porque es más fácil determinar y cubre una porción substancial de los horarios de vista serializable. Determinar serializabilidad-vista de un calendario es una NP-completo problema (una clase de problemas con sólo difícil-a-cálculo, excesivamente lento conocidos soluciones).

Vista-serializabilidad de un programa se define por equivalencia con una programación serial (no operaciones superpuestas) con las mismas transacciones, tales que las transacciones respectivas en los dos programas de leer y escriben que los valores de los mismos datos ("ver" los mismos valores de datos).

Conflicto-serializabilidad se define por equivalencia con una programación serial (no operaciones superpuestas) con las mismas transacciones, tal que ambas listas tienen los mismos conjuntos de respectivos pares cronológicamente ordenados de operaciones conflictivas (mismo relaciones de precedencia de operaciones conflictivas respectivas).

Las operaciones sobre datos leer o escribir (una escritura: o insertar o modificar o borrar). Son dos operaciones conflictivos, si son de diferentes transacciones, sobre el mismo dato (dato), y al menos uno de ellos es escribir. Cada par de tal operaciones conflictivas tiene una tipo de conflicto:: O es un lectura y escritura, o escritura-lectura, o un escritura-escritura conflicto. La transacción de la segunda operación en el par se dice que es en conflicto con la transacción de la primera operación. Una definición más general de operaciones conflictivas (también para operaciones complejas, que pueden consistir en cada una de varias operaciones de lectura/escritura de "simple") requiere que sean No conmutativa (cambia su orden también cambian su resultado combinado). Cada operación de ese tipo debe ser atómica por sí mismo (por el apoyo adecuado del sistema) con el fin de ser considerado como una operación por un cheque de Conmutatividad. Por ejemplo, leer-lectura operaciones son conmutativos (a diferencia de la lectura y escritura y las otras posibilidades) y por lo tanto leer-lectura no es un conflicto. Otro ejemplo más complejo: las operaciones incremento y decremento de un contador Ambos son escribir operaciones (ambos modificar el contador), pero no necesitan ser considerados conflictivos (tipo de escritura-escritura conflicto) puesto que son conmutativo (por lo tanto incremento-decremento no es un conflicto, por ejemplo, ya ha sido apoyado en el viejo IMS de IBM "vía rápida"). Sólo precedencia (orden) en pares de operaciones conflictivas (no conmutativa) es importante al comprobar la equivalencia a una programación serial, desde diferentes horarios que consta de las mismas transacciones pueden transformarse de uno a otro mediante el cambio de órdenes entre las operaciones de las diferentes transacciones (diferentes operaciones interpolación), y puesto que las órdenes de operaciones conmutativas (no conflictivo) no cambiar un resultado global de la secuencia de operación, es decir, un resultado de horario (el resultado se conserva a través del cambio de orden entre las operaciones no conflictivo, pero normalmente no cuando las operaciones conflictivas cambian orden). Esto significa que si un programa puede ser transformado a cualquier programación serial sin cambios órdenes de operaciones conflictivas (pero cambiantes órdenes de no conflictivo, conservando el orden de operación dentro de cada transacción), entonces el resultado de ambos programas es el mismo, y el horario es serializable conflicto por definición.

Los conflictos son la razón para bloquear las transacciones y los retrasos (desmaterializadas conflictos) o para transacciones abortadas debido a la prevención de violaciones serializabilidad. Ambas posibilidades reducen su rendimiento. Por Conmutatividad (cuando sea posible), reduciendo el número de conflictos, por ejemplo, es una manera de aumentar el rendimiento.

Una transacción puede una operación conflictiva/solicitud de emisión y en conflicto con otra transacción mientras su funcionamiento contradictorios es retrasado y no ejecutado (por ejemplo, bloqueado por un cerradura). Sólo se ejecuta)se materializó) operaciones conflictivas son relevantes para serializabilidad conflicto (véase más abajo).

Aplicar serializabilidad conflicto

Prueba serializabilidad conflicto

Horario cumplimiento serializabilidad conflicto puede comprobarse con la gráfico de precedencia (gráfico serializabilidad, gráfico de serialización, gráfico de conflicto) para transacciones confirmadas de la programación. Es el Grafo dirigido representando precedencia de las transacciones en el calendario, como se refleja por prioridad de operaciones conflictivas en las transacciones.

En gráfico de precedencia las transacciones son los nodos y las relaciones de precedencia bordes dirigidos. Existe una arista de una primera transacción a una segunda operación, si es la segunda operación en conflicto con la primera (véase serializabilidad conflicto anterior), y el conflicto es se materializó (es decir, si en realidad se ejecuta la operación solicitada contradictoria: en muchos casos una operación conflictiva solicitados/emitido por una transacción es retrasada e incluso nunca ejecutada, típicamente por un cerradura el objeto de la operación, celebró por otra transacción, o cuando se escribe a espacio de trabajo privado temporal de una transacción y materializando, copiar la base de datos propia, al cometer; mientras no se ejecuta una operación conflictiva solicitados/emitido sobre la base de datos propia, el conflicto es desmaterializadas; desmaterializadas conflictos no están representados por un borde en el gráfico de precedencia).

Comentario: En muchos libros de texto sólo transacciones confirmadas se incluyen en el gráfico de precedencia. Aquí todas las transacciones están incluidas para conveniencia en las discusiones posteriores.

La siguiente observación es un Caracterización clave de serializabilidad conflicto:

Es un programa conflicto serializable Si y sólo si su gráfico de precedencia de transacciones confirmadas (cuando sólo comprometido las transacciones se consideran) es acíclicos. Esto significa que un ciclo consiste en transacciones confirmadas sólo se genera en el gráfico de precedencia (general), si y sólo si se violó el conflicto-serializabilidad.

Ciclos de transacciones confirmadas pueden prevenirse por abortar un indeciso transacción (ni comprometida, ni abortado) en cada ciclo en el gráfico de precedencia de todas las transacciones, que de lo contrario se puede convertir en un ciclo de cometido transacciones (y no puede abortarse una transacción comprometida). Una transacción abortada por ciclo es tanto necesario y suficiente número de romper y eliminar el ciclo (más interrupciones son posibles y pueden ocurrir en algunos mecanismos, pero innecesario para serializabilidad). La probabilidad de generación de ciclo es generalmente baja, pero sin embargo, tal situación es cuidadosamente manejada, típicamente con una sobrecarga considerable, puesto que la corrección está implicado. Las transacciones anuladas debido a una prevención serializabilidad violación son reinicia y otra vez inmediatamente ejecutados.

Serializabilidad ejecución mecanismos típicamente no mantener un gráfico de precedencia como una estructura de datos, pero prefiero evitar o se rompen los ciclos implícitamente (por ej., SS2PL más abajo).

Mecanismo común - SS2PL

Artículo principal: Bloqueo de dos fases

Fuerte dos estrictas de la fase de bloqueo (SS2PL) es un mecanismo común utilizado en sistemas de base de datos desde sus inicios en la década de 1970 (el "SS" en el nombre de SS2PL es más reciente sin embargo) para hacer cumplir tanto serializabilidad conflicto y rigor (un caso especial de recuperación que permite la recuperación de base de datos eficaz de falta) de un calendario. En este mecanismo cada referencia está bloqueado por una transacción antes de acceder a él (cualquier lectura o escritura operación): el elemento está marcado por, asociada a un cerradura de un determinado tipo, dependiendo de la operación (y la implementación específica; existen varios modelos con tipos diferentes cerradura; en algunos modelos de cerraduras pueden cambiar tipo durante la vida de la transacción). Como resultado acceso por otra transacción puede ser bloqueado, típicamente sobre un conflicto (la cerradura retrasa o evita totalmente que el conflicto se materializa y se refleja en el gráfico de precedencia bloqueando el funcionamiento contradictorios), dependiendo del tipo de bloqueo y tipo de operación de acceso de la otra transacción. Empleando un mecanismo de SS2PL significa que todos los bloqueos en los datos en nombre de una transacción son liberados sólo después de que la transacción ha finalizado (cometió o abortado).

SS2PL es el nombre de la propiedad resultante de horario, que también se llama rigurosidad. SS2PL es un (caso especialsubconjunto adecuado) de Bloqueo de dos fases (2PL)

Bloqueo mutuo entre transacciones resulta en un interbloqueo, donde la ejecución de estas transacciones está paralizada, y no puede llegar a ninguna conclusión. Así los interbloqueos necesitan ser resueltos completar la ejecución de estas transacciones y liberar recursos informáticos relacionados. Un bloqueo es un reflejo de un ciclo en el gráfico de precedencia, que se produciría sin el bloqueo cuando se materializan los conflictos potencial. Un interbloqueo resuelve anular una transacción con tal ciclo potencial y romper el ciclo. A menudo se detecta mediante un Espera-gráfico (un gráfico de conflictos bloqueado por bloqueos de ser materializado también puede definirse como el gráfico de conflictos desmaterializadas; no se materializaron los conflictos no se reflejan en el gráfico de precedencia y no afectan serializabilidad), que indica que la transacción es "waiting for" desbloqueo por transacción que, y un ciclo significa un interbloqueo. Anular una transacción por ciclo es suficiente para romper el ciclo. Transacciones anulado debido a una resolución de interbloqueo reinicia y otra vez inmediatamente ejecutados.

Otras técnicas de ejecución

Otros conocidos mecanismos incluyen:

• Gráfico de precedencia (o gráfico serializabilidad, gráfico de conflicto) ciclo de eliminación
• Bloqueo de dos fases (2PL)
• Timestamp pedidos (A)
• Aislamiento de instantánea serializable (SerializableSI)

Las técnicas anteriores de serializabilidad (conflicto) en su forma general no proporcionan capacidad de recuperación. Mejoras especiales son necesarios para agregar capacidad de recuperación.

Optimista versus técnicas pesimistas

Las técnicas de control de concurrencia son de tres tipos principales:

1. Pesimista:: En el control de simultaneidad pesimista una transacción bloquea las operaciones de acceso a datos de otras transacciones sobre los conflictos y los conflictos son desmaterializadas hasta que se elimine el bloqueo. Esto se hace para asegurar que las operaciones que puedan violar serializabilidad (y en la práctica también la capacidad de recuperación) no ocurren.
2. Optimista:: En Control de concurrencia optimista las operaciones de acceso a datos de otras transacciones no están bloqueadas en los conflictos y los conflictos son inmediatamente se materializó. Cuando la transacción alcanza el listo el estado, es decir, su corriendo Estado ha sido completado, posible serializabilidad (y en la práctica también la capacidad de recuperación) se comprueba violación por las operaciones de la transacción (relativamente a otras transacciones corrientes): Si la violación, la transacción es típicamente abortado (a veces abortar otro transacción para manejar violación serializabilidad se prefiere). De lo contrario será comprometido.
3. Semi optimista:: Mecanismos que en ciertas situaciones de bloqueo con el bloqueo en otras situaciones no se mezclan y emplean los conflictos materializados y desmaterializadas

Las principales diferencias entre los tipos de técnica es los tipos de conflictos que se generan por ellos. Un método pesimista bloquea la operación de una transacción sobre conflicto y genera un conflicto desmaterializadas, mientras que un método optimista no bloquea y genera un conflicto materializado. Un método semi optimista genera dos tipos de conflicto. Ambos tipos de conflictos son generados por orden cronológico en que se invocan las operaciones de transacción, independientemente del tipo de conflicto. Un ciclo de transacciones confirmadas (con conflictos materializadas) en el gráfico de precedencia (gráfico de conflicto) representa una violación serializabilidad y debe evitarse para mantener serializabilidad. Un ciclo de conflictos (desmaterializadas) en el Espera-gráfico representa una situación de estancamiento, que debe ser resuelto por romper el ciclo. Ambos tipos de ciclo el resultado de los conflictos y deben ser rotos. En cualquier tipo de técnica los conflictos deben ser detectados y considerados, con gastos similares conflictos materializada y desmaterializadas (normalmente mediante el uso de mecanismos como cerrar, mientras que o bloqueo de cerraduras, o no bloquear pero conflicto conflictos materializada de grabación). En un método de bloqueo típicamente un cambio de contexto se produce al conflicto, con (adicional) incurrido en gastos indirectos. De lo contrario las transacciones bloqueadas relacionadas con recursos informáticos permanecerán inactivo, no utilizados, que puede ser una alternativa peor. Cuando los conflictos no ocurren con frecuencia, los métodos optimistas típicamente tienen una ventaja. Con las transacciones diferentes cargas tipo (mezclas de tipos de transacción) una técnica (es decir, optimista o pesimista) puede proporcionar mejor rendimiento que el otro.

A menos que el horario de clases inherentemente bloqueo (es decir, no pueden ser implementadas sin operaciones de acceso a datos bloqueo; por ejemplo, 2PL, SS2PL y SCO arriba; ver tabla), puede implementar también utilizando técnicas optimistas (por ejemplo, serializabilidad, capacidad de recuperación).

Control de concurrencia multi-versión serializable

Véase también Control de concurrencia multiversión (cobertura parcial)

y Serializable_Snapshot_Isolation en Aislamiento de instantánea

Control de concurrencia multi-versión (MVCC) es una forma común hoy en día para aumentar la concurrencia y el rendimiento mediante la generación de una nueva versión de un objeto de base de datos cada vez que el objeto está escrito, y que permite las transacciones Lee las operaciones de varias versiones pasadas pertinentes (de cada objeto), dependiendo del método de programación. MVCC puede combinarse con todas las técnicas serializabilidad mencionadas (excepto el SerializableSI que es originalmente MVCC basado). Es utilizado en los productos DBMS más polivalente.

MVCC es especialmente popular en la actualidad a través del serializabilidad relajado método (véase arriba) Aislamiento de instantánea (SI) que proporciona mejor rendimiento que la mayoría de los mecanismos conocidos serializabilidad (a costa de violación serializabilidad posible en ciertos casos). SerializableSI, que es una mejora eficiente de SI para que sea serializable, está diseñado para proporcionar una solución eficiente serializable. SerializableSI ha sido analizado mediante una teoría general del MVCC

Serializabilidad distribuido

Resumen

Serializabilidad distribuido es la serializabilidad de un calendario de una transaccional sistema distribuido (por ejemplo, un base de datos distribuida sistema). Dicho sistema se caracteriza por transacciones distribuidas (también llamado transacciones globales), es decir, las transacciones que abarcan los procesos de la computadora (una abstracción del proceso en un sentido general, dependiendo del entorno informático; por ejemplo, Sistema operativoes hilo de rosca) y posiblemente de los nodos de la red. Una transacción distribuida compone de más de uno subtransacciones locales que cada uno tiene Estados como se describió anteriormente para una transacciones de bases de datos. Una transacción local sub compone de un solo proceso o procesos que normalmente no logran juntos (por ejemplo, en una sola núcleo de procesador). Las transacciones distribuidas implican una necesidad en Commit atómico Protocolo para llegar a un consenso entre sus locales subtransacciones sobre si se debe confirmar o anular. Dichos protocolos pueden variar desde un simple (monofásicas)-apretón de manos entre los procesos que no juntos, los protocolos más sofisticados, como Ejecución en dos fases, para manejar los casos más complicados de falla (por ejemplo, proceso, nodo, comunicación, fallas etc.). Serializabilidad distribuida es una meta importante de control de concurrencia distribuido para la corrección. Con la proliferación de la Internet, Computación en la nube, La informatización en redy pequeño, portátil, potente dispositivos informáticos (por ejemplo, smartphones) parece aumentar la necesidad de técnicas eficaces serializabilidad distribuidos asegurar exactitud en y entre las aplicaciones distribuidas.

Serializabilidad distribuido se logra mediante la implementación de versiones distribuidas de las técnicas conocidas centralizadas. Todas estas versiones distribuidas requieren típicamente utilizando información de conflicto (conflictos materializados o desmaterializadas, o equivalente, prioridad de transacción o bloquear información; serializabilidad conflicto se utiliza generalmente) que no se genera localmente, sino en diferentes procesos y ubicaciones remotas. Por lo tanto es necesaria la distribución de la información (por ejemplo, relaciones de precedencia, bloquear información, timestamps o entradas). Cuando el sistema distribuido es de una escala relativamente pequeña, y retrasos del mensaje a través del sistema son pequeños, los métodos de control centralizado simultaneidad pueden utilizarse sin cambios, mientras que ciertos procesos o nodos en el sistema de gestión de los algoritmos relacionados. Sin embargo, en un sistema a gran escala (por ejemplo, Rejilla y Nube), debido a la distribución de dicha información, pena de rendimiento sustanciales típicamente se incurre, incluso cuando se utilizan versiones distribuidas de los métodos (vs centralizada), debido principalmente a la informática y las comunicaciones latencia. Además, cuando dicha información se distribuye, técnicas relacionadas normalmente no escala bien. Un ejemplo bien conocido con problemas de escalabilidad es un Administrador de bloqueos distribuido, que distribuye información de bloqueo (desmaterializadas conflicto) en el sistema distribuido para implementar técnicas de bloqueo.

Véase también

• Fuerte estricto bloqueo de dos fases (SS2PL o rigor).
• Fabricación de aislamiento de instantánea serializable en Aislamiento de instantánea.
• Serializabilidad global, donde el Problema global serializabilidad y sus soluciones propuestas se describen.
• Linearizability, un concepto más general en Computación concurrente

Referencias

• Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman (1987): Control de concurrencia y recuperación en sistemas de base de datos, Addison Wesley Publishing Company, ISBN 0-201-10715-5
• Gerhard Weikum, Gottfried Vossen (2001): Sistemas de información transaccional, Elsevier, ISBN 1-55860-508-8

Otras Páginas

• Fotografia de conservacion
• Lista de formas de Tai chi chuan
• Deuda no asegurada
• Asistencia de operador
• Rapido MTS
• Chad Johnson (seccion de vida Personal)
• Moy Lin-shin
• Radical del Triphenylmethyl
• Diciembre de 2013 Spuyten Duyvil descarrilamiento (redireccion de 2013 New York City tren descarrilamiento)
• 1969 ABA All-Star Game
• COMO un servicio