In der Informationstechnologie und Informatik, besonders in den Feldern von Computerprogrammierung, Betriebssystemen, Mehrverarbeitern und Datenbanken, stellt Parallelitätskontrolle sicher, dass richtige Ergebnisse für gleichzeitige Operationen erzeugt werden, während man jene Ergebnisse so schnell bekommt wie möglich.

Computersysteme, sowohl Software als auch Hardware, bestehen aus Modulen oder Bestandteilen. Jeder Bestandteil wird entworfen, um richtig zu funktionieren, d. h., zu folgen oder bestimmte Konsistenz-Regeln zu entsprechen. Wenn Bestandteile, die gleichzeitig funktionieren, durch die Nachrichtenübermittlung aufeinander wirken oder durch das Teilen auf Daten zugegriffen hat (im Gedächtnis oder der Lagerung), kann eine Konsistenz eines bestimmten Bestandteils durch einen anderen Bestandteil verletzt werden. Das allgemeine Gebiet der Parallelitätskontrolle stellt Regeln, Methoden, Designmethodiken und Theorien zur Verfügung, die Konsistenz von Bestandteilen aufrechtzuerhalten, die gleichzeitig funktionieren, während es, und so die Konsistenz und Genauigkeit des ganzen Systems aufeinander wirkt. Das Einführen der Parallelitätskontrolle in ein System bedeutet, Operationseinschränkungen anzuwenden, die normalerweise auf etwas Leistungsverminderung hinauslaufen. Operationskonsistenz und Genauigkeit sollten mit so gutem erreicht werden wie möglich Leistungsfähigkeit, ohne Leistung unter dem angemessenen zu reduzieren.

Zum Beispiel kann ein Misserfolg in der Parallelitätskontrolle auf Datenbestechung vom gerissenen gelesen hinauslaufen oder Operationen schreiben.

Parallelitätskontrolle in Datenbanken

Anmerkungen:

1. Diese Abteilung ist auf alle transactional Systeme, d. h. auf alle Systeme anwendbar, die Datenbanktransaktionen verwenden (Atomtransaktionen; z.B protestiert transactional im Systemmanagement und in Netzen von smartphones, die normalerweise private, hingebungsvolle Datenbanksysteme durchführen), nicht nur Mehrzweckdatenbankverwaltungssysteme (DBMSs).
2. DBMSs muss sich auch mit Parallelitätskontrollproblemen nicht typisch gerade zu Datenbanktransaktionen, aber eher zu Betriebssystemen im Allgemeinen befassen. Diese Probleme (z.B, sieh Parallelitätskontrolle in Betriebssystemen unten) sind außer dem Spielraum dieser Abteilung.

Parallelitätskontrolle in Datenbankverwaltungssystemen (DBMS; z.B, Bernstein u. a. 1987, Weikum und Vossen 2001), andere Transactional-Gegenstände und verwandte verteilte Anwendungen (z.B, Bratrost-Computerwissenschaft und Wolkencomputerwissenschaft) stellt sicher, dass Datenbanktransaktionen gleichzeitig durchgeführt werden, ohne die Datenintegrität der jeweiligen Datenbanken zu verletzen. So ist Parallelitätskontrolle ein wesentliches Element für die Genauigkeit in jedem System, wo zwei Datenbanktransaktionen oder mehr, durchgeführt mit dem Zeitübergreifen, auf dieselben Daten z.B eigentlich in jedem Mehrzweckdatenbanksystem zugreifen können. Folglich ist ein riesengroßer Körper der zusammenhängenden Forschung angesammelt worden, seitdem Datenbanksysteme am Anfang der 1970er Jahre erschienen sind. Eine gut feststehende Parallelitätssteuerungstheorie für Datenbanksysteme wird in den Verweisungen entworfen, die oben erwähnt sind: Serializability-Theorie, die erlaubt, Parallelitätskontrollmethoden und Mechanismen effektiv zu entwerfen und zu analysieren. Eine alternative Theorie für die Parallelitätskontrolle von Atomtransaktionen über abstrakte Datentypen wird in präsentiert (Lynchen u. a. 1993), und nicht verwertet unten. Diese Theorie, wird Komplex mit einem breiteren Spielraum mehr raffiniert, und ist in der Datenbankliteratur weniger verwertet worden als die klassische Theorie oben. Jede Theorie hat sein Pro und Kontra, Betonung und Scharfsinnigkeit. Einigermaßen sind sie ergänzend, und ihr Mischen kann nützlich sein.

Um Genauigkeit zu sichern, versichert ein DBMS gewöhnlich, dass nur serialisierbare Transaktionslisten erzeugt werden, wenn serializability nicht absichtlich entspannt wird, um Leistung, aber nur in Fällen zu vergrößern, wo Anwendungsgenauigkeit nicht geschadet wird. Um Genauigkeit in Fällen von erfolglosen (abgebrochenen) Transaktionen aufrechtzuerhalten (der immer aus vielen Gründen geschehen kann) müssen Listen auch die Werthaltigkeit (vom Abbruch) Eigentum haben. Ein DBMS versichert auch, dass keine Wirkung von begangenen Transaktionen verloren wird, und keine Wirkung von abgebrochenen (wiederholten) Transaktionen in der zusammenhängenden Datenbank bleibt. Gesamte Transaktionscharakterisierung wird gewöhnlich durch die SAUREN Regeln unten zusammengefasst. Da Datenbanken verteilt geworden sind, oder in verteilten Umgebungen zusammenarbeiten mussten (z.B, Bundesdatenbanken Anfang 1990 und Wolke, die zurzeit rechnet), hat der wirksame Vertrieb von Parallelitätskontrollmechanismen spezielle Aufmerksamkeit erhalten.

Datenbanktransaktion und die SAUREN Regeln

Das Konzept einer Datenbanktransaktion (oder Atomtransaktion) hat sich entwickelt, um beiden ein gut verstandenes Datenbanksystemverhalten in einer fehlerhaften Umgebung zu ermöglichen, wo Unfälle jede Zeit und Wiederherstellung von einem Unfall bis einen gut verstandenen Datenbankstaat zufällig können. Eine Datenbanktransaktion ist eine Einheit der Arbeit, normalerweise mehrere Operationen über eine Datenbank (z.B kurz zusammenfassend, einen Datenbankgegenstand, das Schreiben, Erwerben des Schlosses usw. lesend), eine Abstraktion, die in der Datenbank und auch den anderen Systemen unterstützt ist. Jede Transaktion hat Grenzen gut definiert, in Bezug auf die Ausführungen des Programms/Codes in diese Transaktion (bestimmt vom Programmierer der Transaktion über spezielle Transaktionsbefehle) eingeschlossen werden. Jede Datenbanktransaktion folgt den folgenden Regeln (durch die Unterstützung im Datenbanksystem; d. h. ein Datenbanksystem wird entworfen, um sie für die Transaktionen zu versichern, die es führt):

• Atomicity - Entweder die Effekten von allen oder bleibt keine seiner Operationen ("alle oder nichts" Semantik), wenn eine Transaktion (begangen oder abgebrochen beziehungsweise) vollendet wird. Mit anderen Worten zur Außenwelt scheint eine begangene Transaktion (durch seine Effekten auf die Datenbank), unteilbar, atomar zu sein, und eine abgebrochene Transaktion verlässt Effekten auf die Datenbank überhaupt nicht, als ob nie bestanden hat.
• Konsistenz - Jede Transaktion muss die Datenbank in einem konsequenten (richtigen) Staat verlassen, d. h., die vorher bestimmten Integritätsregeln der Datenbank (Einschränkungen auf und unter den Gegenständen der Datenbank) aufrechterhalten. Eine Transaktion muss eine Datenbank von einem konsequentem Staat bis einen anderen konsequenten Staat umgestalten (jedoch, es ist die Verantwortung des Programmierers der Transaktion sicherzustellen, dass die Transaktion selbst richtig ist, d. h., richtig durchführt, was es vorhat durchzuführen (aus dem Gesichtspunkt der Anwendung), während die vorherbestimmten Integritätsregeln durch den DBMS beachtet werden). So, da eine Datenbank normalerweise nur durch Transaktionen geändert werden kann, entsprechen Staaten ganzen Datenbank. Eine abgebrochene Transaktion ändert den Datenbankstaat nicht, von dem sie angefangen hat, als ob sie nie (atomicity oben) bestanden hat.
• Isolierung - Transaktionen können einander (als ein Endergebnis ihrer Ausführungen) nicht stören. Außerdem, gewöhnlich (je nachdem Parallelitätskontrollmethode) die Effekten einer unvollständigen Transaktion sind zu einer anderen Transaktion nicht sogar sichtbar. Versorgung der Isolierung ist die Hauptabsicht der Parallelitätskontrolle.
• Beständigkeit - Effekten von erfolgreichen (begangenen) Transaktionen müssen durch Unfälle (normalerweise durch die Aufnahme der Effekten der Transaktion und seines andauern, Ereignis in einem nichtflüchtigen Speicher begangen).

Das Konzept der Atomtransaktion ist während der Jahre dazu erweitert worden, was Geschäftstransaktionen geworden ist, die wirklich Typen des Arbeitsablaufs durchführen und nicht atomar sind. Jedoch auch verwerten solche erhöhten Transaktionen normalerweise Atomtransaktionen als Bestandteile.

Warum ist Parallelitätskontrolle erforderlich?

Wenn Transaktionen serienmäßig, d. h. folgend ohne Übergreifen rechtzeitig durchgeführt werden, besteht keine Transaktionsparallelität. Jedoch, wenn gleichzeitigen Transaktionen mit dem Durchschießen von Operationen auf eine nicht kontrollierte Weise erlaubt wird, kann ein unerwartetes, unerwünschtes Ergebnis vorkommen. Hier sind einige typische Beispiele:

1. Das verlorene Aktualisierungsproblem: Eine zweite Transaktion schreibt einen zweiten Wert eines Datenartikels (Gegebenheit) oben auf einem ersten Wert, der durch eine erste gleichzeitige Transaktion geschrieben ist, und der erste Wert wird gegen andere Transaktionen verloren, die gleichzeitig der Bedürfnis durch ihre Priorität laufen, den ersten Wert zu lesen. Die Transaktionen, die das falsche Wertende mit falschen Ergebnissen gelesen haben.
2. Das schmutzige gelesene Problem: Transaktionen lesen einen Wert, der durch eine Transaktion geschrieben ist, die später abgebrochen worden ist. Dieser Wert verschwindet von der Datenbank auf den Abbruch, und sollte durch keine Transaktion ("schmutzig gelesen") gelesen worden sein. Die Lesen-Transaktionen enden mit falschen Ergebnissen.
3. Das falsche zusammenfassende Problem: Während eine Transaktion eine Zusammenfassung über die Werte aller Beispiele eines wiederholten Datenartikels nimmt, aktualisiert eine zweite Transaktion einige Beispiele dieses Datenartikels. Die resultierende Zusammenfassung widerspiegelt kein richtiges Ergebnis für keinen (gewöhnlich erforderlich für die Genauigkeit) Prioritätsordnung zwischen den zwei Transaktionen (wenn man vor dem anderen durchgeführt wird), aber eher ein zufälliges Ergebnis, abhängig vom Timing der Aktualisierungen, und ob bestimmte Aktualisierungsergebnisse in die Zusammenfassung eingeschlossen worden sind oder nicht.

Die meisten transactional Hochleistungssysteme müssen Transaktionen gleichzeitig führen, um ihren Leistungsanforderungen zu entsprechen. So, ohne Parallelität kontrollieren solche Systeme kann richtige Ergebnisse weder zur Verfügung stellen noch ihre konsequenten Datenbanken aufrechterhalten.

Parallelitätskontrollmechanismen

Kategorien

Die Hauptkategorien von Parallelitätskontrollmechanismen sind:

• Optimistisch - Verzögerung die Überprüfung dessen, ob eine Transaktion die Isolierung und anderen Integritätsregeln (z.B, serializability und Werthaltigkeit) bis zu seinem Ende entspricht, ohne einigen von seinem zu blockieren (gelesen, schreiben Sie) Operationen ("... und über die Regeln optimistisch sein, die... "entsprechen werden), und dann brechen Sie eine Transaktion ab, um die Übertretung zu verhindern, wenn die gewünschten Regeln auf seinen verletzt werden sollen begehen. Eine abgebrochene Transaktion wird sofort wiederangefangen und wiederdurchgeführt, der einen offensichtlichen oberirdischen (gegen die Durchführung davon zum Ende nur einmal) übernimmt. Wenn nicht zu viele Transaktionen werden abgebrochen, dann optimistisch zu sein, ist gewöhnlich eine gute Strategie.
• Pessimistisch - Block verschwindet eine Operation einer Transaktion, wenn es Übertretung der Regeln bis zur Möglichkeit der Übertretung verursachen kann. Das Blockieren von Operationen wird normalerweise mit der Leistungsverminderung beteiligt.
• Halboptimistisch - Block-Operationen in einigen Situationen, wenn sie Übertretung von einigen Regeln verursachen können, und in anderen Situationen nicht blockieren, während sie Regeln verzögern, die (wenn erforderlich) zum Ende der Transaktion, wie getan, mit dem optimistischen überprüfen.

Verschiedene Kategorien stellen verschiedene Leistung, d. h., verschiedene durchschnittliche Transaktionsvollziehungsraten (Durchfluss), abhängig von der Bewegungsart-Mischung, dem Rechenniveau des Parallelismus und den anderen Faktoren zur Verfügung. Wenn Auswahl und Kenntnisse über Umtausche verfügbar sind, dann sollten Kategorie und Methode gewählt werden, um die höchste Leistung zur Verfügung zu stellen.

Das gegenseitige Blockieren zwischen zwei Transaktionen (wo jeder den anderen blockiert) oder läuft mehr auf einen toten Punkt hinaus, wo die beteiligten Transaktionen eingestellt werden und Vollziehung nicht erreichen können. Die meisten nichtoptimistischen Mechanismen (mit dem Blockieren) sind für tote Punkte anfällig, die durch einen absichtlichen Abbruch einer eingestellten Transaktion aufgelöst werden (der die anderen Transaktionen in diesem toten Punkt veröffentlicht), und sein unmittelbarer Wiederanfang und Wiederausführung. Die Wahrscheinlichkeit eines toten Punktes ist normalerweise niedrig.

Sowohl das Blockieren, die toten Punkte als auch die Abbrüche laufen auf die Leistungsverminderung, und folglich die Umtausche zwischen den Kategorien hinaus.

Methoden

Viele Methoden für die Parallelitätskontrolle bestehen. Die meisten von ihnen können innerhalb jeder Hauptkategorie oben durchgeführt werden. Die Hauptmethoden, die jeden viele Varianten haben, und in einigen Fällen überlappen oder verbunden werden können, sind:

1. Die Blockierung (z.B, Zweiphasige Blockierung - 2PL) - das Steuern des Zugangs zu Daten durch den Daten zugeteilte Schlösser. Der Zugang einer Transaktion zu einem Datenartikel (Datenbankgegenstand) geschlossen durch eine andere Transaktion kann blockiert werden (je nachdem Typ und Zugriffsoperationstyp schließen) bis zur Schloss-Ausgabe.
2. Anordnungsgraph-Überprüfung (hat auch Serializability, oder Konflikt oder Prioritätsgraph-Überprüfung genannt) - für Zyklen im Graphen der Liste Überprüfend und sie durch Abbrüche brechend.
3. Zeitstempel-Einrichtung (TO) - das Zuweisen von Zeitstempeln zu Transaktionen, und dem Steuern oder der Überprüfung des Zugangs zu Daten durch die Zeitstempel-Ordnung.
4. Engagement, das bestellt (oder Verpflichten zu bestellen; CO) - die zeitliche Reihenfolge von kontrollierenden oder überprüfenden Transaktionen dessen begehen Ereignisse, um mit ihrer jeweiligen Prioritätsordnung vereinbar zu sein.

Andere Hauptparallelität kontrolliert Typen, die in Verbindung mit den Methoden oben verwertet werden, schließen Sie ein:

• Mehrversionsparallelitätskontrolle (MVCC) - Zunehmende Parallelität und Leistung durch das Erzeugen einer neuen Version einer Datenbank protestieren jedes Mal, wenn der Gegenstand, und die gelesenen Operationen von erlaubenden Transaktionen von mehreren letzten relevanten Versionen (von jedem Gegenstand) abhängig von Terminplanung der Methode geschrieben wird.
• Index-Parallelitätskontrolle - Gleichzeitig seiende Zugriffsoperationen zu Indizes, aber nicht zu Benutzerdaten. Spezialmethoden stellen wesentliche Leistungszunahmen zur Verfügung.
• Privates Arbeitsraum-Modell (Aufgeschobene Aktualisierung) - Jede Transaktion erhält einen privaten Arbeitsraum für seine zugegriffenen Daten aufrecht, und seine geänderten Daten werden sichtbar außerhalb der Transaktion nur auf seinen (z.B, Weikum und Vossen 2001) begehen. Dieses Modell versorgt ein verschiedenes Parallelitätskontrollverhalten mit Vorteilen in vielen Fällen.

Der allgemeinste Mechanismus-Typ in Datenbanksystemen seit ihren frühen Tagen ist in den 1970er Jahren Starke strenge Zweiphasige Blockierung gewesen (SS2PL; auch genannt Strenge Terminplanung oder Streng 2PL), der ein spezieller Fall (Variante) sowohl der Zweiphasigen Blockierung (2PL) als auch Engagement-Einrichtung (CO) ist. Es ist pessimistisch. Trotz seines langen Namens (aus historischen Gründen) ist die Idee vom SS2PL Mechanismus einfach: "Veröffentlichen Sie alle Schlösser, die durch eine Transaktion nur angewandt sind, nachdem die Transaktion geendet hat." SS2PL (oder Strengkeit) ist auch der Name des Satzes aller Listen, die durch diesen Mechanismus erzeugt werden können, d. h. diese sind SS2PL (oder Streng) Listen, haben den SS2PL (oder Strengkeit) Eigentum.

Hauptabsichten der Parallelität kontrollieren Mechanismen

Parallelitätskontrollmechanismen müssen erstens richtig funktionieren, d. h., um die Integritätsregeln jeder Transaktion aufrechtzuerhalten (wie verbunden, mit der Parallelität; anwendungsspezifische Integritätsregel ist außer dem Spielraum hier), während Transaktionen gleichzeitig, und so die Integrität des kompletten transactional Systems laufen. Genauigkeit muss mit der so guten Leistung erreicht werden wie möglich. Außerdem zunehmend besteht ein Bedürfnis, um effektiv zu funktionieren, während Transaktionen über Prozesse, Computer und Computernetze verteilt werden. Andere Themen, die Parallelitätskontrolle betreffen können, sind Wiederherstellung und Erwiderung.

Genauigkeit

Serializability

Für die Genauigkeit erzeugt eine allgemeine Hauptabsicht von den meisten Parallelitätskontrollmechanismen Listen mit dem Eigentum von Serializability. Ohne serializability unerwünschte Phänomene kann z.B vorkommen, Geld kann von Rechnungen verschwinden, oder aus dem Nichts erzeugt werden. Serializability einer Liste hat Gleichwertigkeit (in den resultierenden Datenbankwerten) zu einer Serienliste mit denselben Transaktionen vor (d. h., in dem Transaktionen ohne Übergreifen rechtzeitig folgend, und so von einander völlig isoliert sind: Kein gleichzeitiger Zugang durch irgendwelche zwei Transaktionen zu denselben Daten ist möglich). Serializability wird als das höchste Niveau der Isolierung unter Datenbanktransaktionen und das Hauptgenauigkeitskriterium für gleichzeitige Transaktionen betrachtet. In einigen Fällen wird in Verlegenheit gebrachten, entspannten Formen von serializability für die bessere Leistung erlaubt (z.B. Der populäre Schnellschuss-Isolierungsmechanismus) oder Verfügbarkeitsanforderungen in hoch verteilten Systemen zu entsprechen (sieh Schließliche Konsistenz), aber nur wenn die Genauigkeit der Anwendung durch die Entspannung nicht verletzt wird (z.B wird keiner Entspannung für Geldtransaktionen seitdem durch das Entspannungsgeld erlaubt, kann verschwinden, oder aus dem Nichts erscheinen).

Fast alle durchgeführten Parallelitätskontrollmechanismen erreichen serializability durch die Versorgung des Konflikts serializablity, eines breiten speziellen Falls von serializability (d. h. es bedeckt, ermöglicht die meisten serialisierbaren Listen, und erlegt bedeutende zusätzliche Verzögerung verursachende Einschränkungen nicht auf), der effizient durchgeführt werden kann.

Werthaltigkeit

:See-Werthaltigkeit in Serializability

Anmerkung: Während im allgemeinen Gebiet von Systemen sich der Begriff "Werthaltigkeit" auf die Fähigkeit eines Systems beziehen kann, sich von Misserfolg oder von einem falschen/verbotenen Staat innerhalb der Parallelitätskontrolle von Datenbanksystemen zu erholen, hat dieser Begriff eine spezifische Bedeutung erhalten.

Parallelitätskontrolle sichert normalerweise auch das Werthaltigkeitseigentum von Listen, um Genauigkeit in Fällen von abgebrochenen Transaktionen aufrechtzuerhalten (der immer aus vielen Gründen geschehen kann). Werthaltigkeit (vom Abbruch) bedeutet, dass keine begangene Transaktion in einer Liste durch eine abgebrochene Transaktion geschriebene Daten gelesen hat. Solche Daten verschwinden von der Datenbank (auf den Abbruch) und sind Teile eines falschen Datenbankstaates. Das Lesen solcher Daten verletzt die Konsistenz-Regel von SÄURE. Verschieden von Serializability, Werthaltigkeit kann nicht in Verlegenheit gebracht, an jedem Fall entspannt werden, da läuft jede Entspannung auf schnelle Datenbankintegritätsübertretung auf Abbrüche hinaus. Die Hauptmethoden, die oben verzeichnet sind, stellen serializability Mechanismen zur Verfügung. Keiner von ihnen in seiner allgemeinen Form stellt automatisch Werthaltigkeit zur Verfügung, und spezielle Rücksichten und Mechanismus-Erhöhungen sind erforderlich, um Werthaltigkeit zu unterstützen. Ein allgemein verwerteter spezieller Fall der Werthaltigkeit ist Strenge, die effiziente Datenbankwiederherstellung vom Misserfolg erlaubt (aber schließt optimistische Durchführungen aus; z.B kann Strict CO (SCO) keine optimistische Durchführung haben, aber hat halboptimistische).

Anmerkung: Bemerken Sie, dass das Werthaltigkeitseigentum erforderlich ist, selbst wenn kein Datenbankmisserfolg vorkommt und keine Datenbankwiederherstellung vom Misserfolg erforderlich ist. Es ist zu richtig automatisch Griff-Transaktionsabbrüchen eher erforderlich, die zum Datenbankmisserfolg und der Wiederherstellung davon ohne Beziehung sein können.

Vertrieb

Mit der schnellen technologischen Entwicklung, den Unterschied zwischen der lokalen und verteilten Computerwissenschaft über niedrige Latenz-Netze oder Busse zu schätzen, verschwimmt. So ist die ziemlich wirksame Anwendung von lokalen Techniken in solchen verteilten Umgebungen, z.B, in Computertrauben und Mehrkernverarbeitern üblich. Jedoch haben die lokalen Techniken ihre Beschränkungen und verwenden Mehrprozesse (oder Fäden) unterstützt durch Mehrverarbeiter (oder Mehrkerne), um zu klettern. Das verwandelt häufig Transaktionen in verteilte, wenn sie selbst Mehrprozesse abmessen müssen. In diesen Fällen klettern die meisten lokalen Parallelitätskontrolltechniken gut nicht.

Verteilter serializability und Engagement-Einrichtung

:See Verteilter serializability in Serializability

Da Datenbanksysteme verteilt geworden sind oder angefangen haben, in verteilten Umgebungen zusammenzuarbeiten (z.B, Bundesdatenbanken am Anfang der 1990er Jahre, und heutzutage Bratrost-Computerwissenschaft, Wolkencomputerwissenschaft und Netze mit smartphones), sind einige Transaktionen verteilt geworden. Eine verteilte Transaktion bedeutet, dass die Transaktionsspanne-Prozesse, und Computer und geografische Seiten abmessen können. Das erzeugt ein Bedürfnis in wirksamen verteilten Parallelitätskontrollmechanismen. Das Erzielen des Eigentums von Serializability einer Liste eines verteilten Systems (sieh Verteilten serializability und Globalen serializability (Modularer serializability)), stellt effektiv spezielle Herausforderungen auf, die normalerweise nicht durch die meisten regelmäßigen serializability Mechanismen ursprünglich entsprochen sind, entworfen, um lokal zu funktionieren. Das ist besonders wegen eines Bedürfnisses im kostspieligen Vertrieb der Parallelitätssteuerinformation mitten in der Kommunikation und Computerlatenz. Die einzige bekannte allgemeine wirksame Technik für den Vertrieb ist Engagement-Einrichtung, die öffentlich 1991 (nach dem patentieren) bekannt gegeben wurde. Engagement, das bestellt (Verpflichten, CO zu bestellen; 1992 von Raz) bedeutet, dass die zeitliche Reihenfolge von Transaktionen dessen Ereignisse begeht, wird vereinbar mit ihrer jeweiligen Prioritätsordnung behalten. CO verlangt den Vertrieb der Parallelitätssteuerinformation nicht und stellt eine allgemeine wirksame Lösung (zuverlässig, Hochleistungs-, und ersteigbar) sowohl für verteilten als auch für globalen serializability, auch in einer heterogenen Umgebung mit Datenbanksystemen (oder andere Transactional-Gegenstände) mit dem verschiedenen (irgendwelche) Parallelitätskontrollmechanismen zur Verfügung. CO ist gleichgültig, zu dem Mechanismus verwertet wird, da es keine Transaktionsoperationsterminplanung stört (den die meisten Mechanismen kontrollieren), und nur beschließt, dass die Ordnung dessen Ereignisse begeht. Thus, CO ermöglicht den effizienten Vertrieb aller anderen Mechanismen und auch den Vertrieb einer Mischung von verschiedenen (irgendwelche) lokalen Mechanismen, um verteilten und globalen serializability zu erreichen. Die Existenz solch einer Lösung ist "unwahrscheinlich" bis 1991, und von vielen Experten auch später wegen des Missverständnisses der CO Lösung betrachtet worden (sieh Zitate in Globalem serializability). Ein wichtiger Seitenvorteil von CO ist automatische verteilte Entschlossenheit des toten Punktes. Gegen CO eigentlich sind alle anderen Techniken (wenn nicht verbunden mit CO) für verteilte tote Punkte anfällig (auch hat globale tote Punkte genannt), die das spezielle Berühren brauchen. CO ist auch der Name des resultierenden Termineigentums: Eine Liste hat das CO Eigentum, wenn die zeitliche Reihenfolge seiner Transaktionen Ereignisse begeht, ist mit der Priorität der jeweiligen Transaktionen (teilweise) Ordnung vereinbar.

SS2PL, der oben erwähnt ist, ist eine Variante (spezieller Fall) von CO und so auch wirksam, um verteilten und globalen serializability zu erreichen. Es stellt auch automatische verteilte Entschlossenheit des toten Punktes (eine Tatsache zur Verfügung, die in der Forschungsliteratur sogar nach der Veröffentlichung von CO überblickt ist), sowie Strenge und so Werthaltigkeit. Das Besitzen dieser gewünschten Eigenschaften zusammen mit der bekannten effizienten Blockierung hat Durchführungen gestützt erklärt SS2PL's Beliebtheit. SS2PL ist verwertet worden, um Verteilten und Globalen serializability seit 1980 effizient zu erreichen, und ist die allgemeine Norm dafür geworden. Jedoch blockiert SS2PL und beschränkt (pessimistisch), und mit der Proliferation des Vertriebs und der Anwendung von von traditionellen Datenbanksystemen verschiedenen Systemen (z.B, als in der Wolkencomputerwissenschaft), weniger Begrenzen-Typen von CO (z.B, Optimistic CO) können für die bessere Leistung erforderlich sein.

Anmerkungen:

1. Der Verteilte Konflikt serializability Eigentum in seiner allgemeinen Form ist schwierig, effizient zu erreichen, aber es wird effizient über seinen speziellen Fall Distributed CO erreicht: Jeder lokale Bestandteil (z.B, ein lokaler DBMS) müssen sowohl eine Form von CO zur Verfügung stellen, als auch eine spezielle Stimmeneinrichtungsstrategie für das Zweiphasige geltend zu machen, begehen Protokoll (2PC: Verwertet, um verteilte Transaktionen zu begehen). Verschieden von allgemeiner Distributed CO besteht Verteilter SS2PL automatisch, wenn alle lokalen Bestandteile gestützter SS2PL sind (in jedem bildenden CO, besteht einbezogen, und die Stimmeneinrichtungsstrategie wird jetzt automatisch entsprochen). Diese Tatsache ist bekannt und verwertet gewesen seit den 1980er Jahren (d. h. das besteht SS2PL allgemein, ohne über CO zu wissen), für effizienten Verteilten SS2PL, der Verteilten serializability und Strenge einbezieht (z.B, sieh Raz 1992, Seite 293; es wird auch in Bernstein einbezogen u. a. 1987, Seite 78). Weniger gezwungener Verteilter serializability und Strenge können von Distributed Strict CO (SCO), oder durch eine Mischung von gestütztem SS2PL effizient erreicht werden, und SCO hat lokale Bestandteile gestützt.
2. Über die Verweisungen und das Engagement, das bestellt: (Bernstein u. a. 1987) wurde vor der Entdeckung von CO 1990 veröffentlicht. Das CO-Termineigentum wird Dynamischer atomicity herbeigerufen (Lynchen u. a. 1993, Seite 201). CO wird darin beschrieben (Weikum und Vossen 2001, Seiten 102, 700), aber die Beschreibung ist teilweise und verpasst die Essenz von CO. (Raz 1992) war das erste, das Schiedsrichter gewesen und für den Veröffentlichungsartikel über CO Algorithmen akzeptiert ist (jedoch, Veröffentlichungen über ein gleichwertiges Dynamisches atomicity Eigentum können bis 1988 verfolgt werden). Andere Artikel CO sind gefolgt. (Bernstein und Neuling 2009) bemerken CO als eine der vier Hauptparallelitätskontrollmethoden und die Fähigkeit von CO, Zwischenfunktionsfähigkeit unter anderen Methoden zur Verfügung zu stellen.

Verteilte Werthaltigkeit

Verschieden von Serializability können Verteilte Werthaltigkeit und Verteilte Strenge effizient auf eine aufrichtige Weise ähnlich zur Weise erreicht werden, wie Distributed CO erreicht wird: In jedem Datenbanksystem müssen sie lokal angewandt werden, und verwenden eine Stimmeneinrichtungsstrategie für das Zweiphasige begehen Protokoll (2PC; Raz 1992, Seite 307).

Wie oben, Verteilter SS2PL, einschließlich der Verteilten Strenge (Werthaltigkeit) und des Verteilten Engagements erwähnt worden ist (serializability) bestellend, automatisch die erforderliche Stimmeneinrichtungsstrategie verwendet, und (allgemein) wenn verwendet, lokal in jedem (lokalen) Datenbanksystem erreicht wird (wie bekannt und viele Jahre lang verwertet gewesen ist; eigentlich wird Gegend durch die Grenze 2PC Teilnehmer (Raz 1992)) definiert.

Andere Hauptthemen der Aufmerksamkeit

Das Design von Parallelitätskontrollmechanismen ist häufig unter Einfluss der folgenden Themen:

Wiederherstellung

Alle Systeme sind für Misserfolge anfällig, und die behandelnde Wiederherstellung vom Misserfolg ist ein Müssen. Die Eigenschaften der erzeugten Listen, die durch den Parallelitätskontrollmechanismus diktiert werden, können einen Einfluss auf die Wirksamkeit und Leistungsfähigkeit der Wiederherstellung haben. Zum Beispiel ist das Strenge-Eigentum (erwähnt in der Abteilungswerthaltigkeit oben) häufig für eine effiziente Wiederherstellung wünschenswert.

Erwiderung

Für die hohe Verfügbarkeit werden Datenbankgegenstände häufig wiederholt. Aktualisierungen von Repliken desselben Datenbankgegenstands müssen synchronisiert behalten werden. Das kann die Weise betreffen, wie Parallelitätskontrolle getan wird (z.B, Gray u. a. 1996).

Siehe auch

• Liste
• Isolierung (Informatik)
• Verteilte Parallelitätskontrolle
• Globale Parallelitätskontrolle

Kommentare

Parallelitätskontrolle in Betriebssystemen

Betriebssysteme, besonders schritthaltende Betriebssysteme stark mehrzubeanspruchen, muss das Trugbild aufrechterhalten, dass alle Aufgaben, die oben auf ihnen laufen, alle zur gleichen Zeit laufen, wenn auch nur eine oder einige Aufgaben wirklich in jedem gegebenen Moment wegen der Beschränkungen der Hardware laufen, auf der das Betriebssystem läuft. Solches Mehrbeschäftigen ist ziemlich einfach, wenn alle Aufgaben von einander unabhängig sind. Jedoch, wenn mehrere Aufgaben versuchen, dieselbe Quelle zu verwenden, oder wenn Aufgaben versuchen, Information zu teilen, kann sie zu Verwirrung und Widersprüchlichkeit führen. Die Aufgabe der gleichzeitigen Computerwissenschaft ist, dieses Problem zu beheben. Einige Lösungen schließen "Schlösser" ein, die den in Datenbanken verwendeten Schlössern ähnlich sind, aber sie riskieren, Probleme ihres eigenen wie toter Punkt zu verursachen. Andere Lösungen sind Blockierungsfreie Algorithmen.

Siehe auch

• Linearizability
• Gegenseitiger Ausschluss
• Semaphor, (programmierend)
• Schloss (Informatik)
• Software transactional Gedächtnis
• Transactional Synchronisationserweiterungen

• Andrew S. Tanenbaum, Albert S Woodhull (2006): Systemdesign und Durchführung, 3. Ausgabe, Prentice Hall, internationale Standardbuchnummer 0-13-142938-8 bedienend