Nebenläufigkeit und Sperren

Zur Sicherstellung der Datenintegrität wenden alle Datenbankmanagementsysteme (DBMSs) Sperren auf Daten an. Wenn ein Benutzer beispielsweise mit dem Aktualisieren von Zeilen beginnt, werden die Zeilen gesperrt, um Änderungen an diesen Zeilen durch andere Benutzer zu verhindern. Sobald die Transaktion abgeschlossen ist, werden die Sperren aufgehoben.

In jedem DBMS werden Sperren auf verschiedene Weise angewendet, und Isolationsgrade werden unterschiedlich interpretiert. Zudem arbeitet ArcGIS nicht mit jedem DBMS auf dieselbe Weise. Deshalb sind unterschiedliche Probleme mit der Nebenläufigkeit beim Durchführen nicht versionierter Änderungen zwischen den verschiedenen DBMS möglich. In diesem Thema erhalten Sie eine kurze Einführung zu Nebenläufigkeit und Sperren im Zusammenhang mit ArcGIS. Ausführlichere Informationen erhalten Sie in der DBMS-Dokumentation.

ArcGIS und Isolationsgrade

Wenn Sie eine Oracle-, DB2- oder Informix-Geodatabase in einer nicht versionierten Editiersitzung bearbeiten, gelten dieselben DBMS-Sperrmechanismen wie bei der Arbeit mit jeder anderen Anwendung – diese Umgebung wird von ArcGIS nicht durch Festlegen des Isolationsgrades modifiziert. Stattdessen wird der aktuell im DBMS festgelegte Isolationsgrad verwendet. Daher können Sie die Isolation auf einen beliebigen Grad festlegen und diesen beim Bearbeiten in einer nicht versionierten Editiersitzung verwenden.

Wenn Sie eine SQL Server-Geodatabase in einer nicht versionierten Editiersitzung bearbeiten, legt ArcGIS den Isolationsgrad vor jeder Transaktion auf UNCOMMITTED READ fest. Es besteht keine Möglichkeit, dieses Verhalten zu ändern oder zu umgehen. Wenn Sie den Isolationsgrad vor einer Transaktion auf einen anderen Wert festlegen, wird dieser von ArcGIS vor dem Transaktionsbeginn auf UNCOMMITTED READ zurückgesetzt.

In den folgenden Abschnitten werden mögliche Probleme mit der Nebenläufigkeit unter gängigen Bedingungen erläutert. Soweit nicht anderweitig ausgeführt, wird bei diesen Erläuterungen davon ausgegangen, dass im zugrunde liegenden DBMS der standardmäßige Isolationsgrad COMMITTED READ oder dessen Entsprechung festgelegt ist.

Oracle

Schreibvorgänge blockieren Schreibvorgänge: Wenn Sie einen Bearbeitungsvorgang für ein Feature oder eine Gruppe von Features ausführen, z. B. diese verschieben oder deren Attribute ändern, werden die Zeilen durch das DBMS gesperrt. Die Features bleiben gesperrt, bis Sie die Editiersitzung speichern oder ohne zu speichern beenden. Daher wird jedes bearbeitete Feature oder jeder bearbeitete Datensatz für die Dauer der Editiersitzung gesperrt.

Wenn zwei Benutzer versuchen, dasselbe Feature gleichzeitig zu bearbeiten, wird das Feature gesperrt, sobald der erste Benutzer einen Vorgang abschließt. Die Sperre wird aufrechterhalten, selbst wenn dieser Benutzer mit der Arbeit an anderen Features begonnen hat. Das Feature bleibt gesperrt, bis dieser Benutzer es speichert und somit die Änderungen in der Datenbank festschreibt oder die Editiersitzung ohne Speichern beendet, wodurch alle in dieser Editiersitzung vorgenommenen Bearbeitungen rückgängig gemacht werden.

Während der Sperre des Features versucht der zweite Benutzer, dasselbe Feature zu bearbeiten. Die ArcMap-Sitzung des zweiten Benutzers wartet bis zur Freigabe der Sperren, wobei die vertraute Sanduhr angezeigt wird. Die Sanduhr wird angezeigt, bis die Sperre aufgehoben wird, nachdem der erste Benutzer die Änderungen speichert (die Änderungen in der Datenbank festschreibt) oder die Editiersitzung ohne Speichern der Änderungen beendet (die Bearbeitungen verwirft). Anschließend wird die Sanduhr auf dem Bildschirm des zweiten Benutzers ausgeblendet. Der zweite Benutzer kann nun seine Bearbeitungen ausführen. (Dies bedeutet allerdings, dass die Änderungen des zweiten Benutzers die des ersten überschreiben.)

Dieses Sperrproblem kann auch gleichzeitig für zwei Benutzer auftreten, wenn folgende Umstände vorliegen:

• Die zwei Benutzer führen gleichzeitig Bearbeitungsvorgänge aus.
• Die Benutzer haben Zeilen in ihrer jeweils aktuellen Editiersitzung geändert.
• Beide Benutzer versuchen, eine Zeile zu ändern, die bereits vom jeweils anderen Benutzer geändert wurde.

Für den ersten Benutzer, der versucht, eine gesperrte Zeile zu ändern, wird eine Sanduhr angezeigt, während die ArcMap-Sitzung auf die Aufhebung der Sperre wartet. Wenn der zweite Benutzer versucht, eine durch den ersten Benutzer gesperrte Zeile zu ändern, tritt eine so genannte Deadlock-Situation ein, weil sich nun beide Benutzer gegenseitig blockieren. Das DBMS wählt automatisch eine der Transaktionen aus, deren Änderungen zurückgesetzt werden, sodass die andere fortgesetzt werden kann. Der Benutzer, dessen Transaktion zurückgesetzt wurde, muss alle Bearbeitungsvorgänge wiederholen, die seit dem letzten Speichern vorgenommen wurden.

Schreibvorgänge blockieren keine Lesevorgänge: Benutzer, die in die Datenbank schreiben, verhindern nicht, dass andere Benutzer dieselben Daten lesen, wobei der Isolationsgrad keine Rolle spielt. Dem Benutzer, der die gesperrten Daten liest, werden diese im Zustand vor dem Beginn der aktuellen Transaktion angezeigt.

Lesevorgänge blockieren keine Schreibvorgänge: Benutzer, die die Datenbank lesen, verhindern nicht, dass andere Benutzer dieselben Daten ändern können, wobei der Isolationsgrad keine Rolle spielt.

DB2 und Informix

Schreibvorgänge blockieren Schreibvorgänge: Schreibvorgänge blockieren Schreibvorgänge in DB2 und Informix ähnlich wie in Oracle. Weitere Informationen hierzu finden Sie in den Erläuterungen zu Oracle.

Schreibvorgänge blockieren Lesevorgänge: In DB2 und Informix verhindern Schreibvorgänge, dass andere Benutzer dieselben Daten lesen können; dies gilt für jeden Isolationsgrad oberhalb von UNCOMMITTED READ. Bei diesen höheren Isolationsgraden kann das Sperren der Daten bis zum Speichern bzw. bis zum Zurücksetzen der Änderungen zu Nebenläufigkeitsproblemen führen. Solange Sie in einer Editiersitzung arbeiten, können die von Ihnen bearbeiteten Daten von keiner anderen Person gelesen werden. Dies kann zu folgenden Situationen führen:

• Wenn ein anderer Benutzer in ArcMap denselben Layer hinzufügt, wird die Sanduhr angezeigt und der Layer wird erst nach dem Aufheben der Sperren gezeichnet.
• Wenn ein anderer Benutzer versucht, die Ansicht der bearbeiteten Daten zu schwenken, wartet ArcMap bis zum Aufheben der Sperre und aktualisiert anschließend die Anzeige.
• Wenn ein anderer Benutzer ein gesperrtes Feature identifiziert, wird die Sanduhr angezeigt, und bis zum Aufheben der Sperre werden keine Informationen zurückgegeben.

Lesevorgänge blockieren Schreibvorgänge: In DB2 und Informix verhindern Lesevorgänge bei einem beliebigen Isolationsgrad über UNCOMMITTED READ möglicherweise, dass andere Benutzer dieselben Daten ändern. In ArcGIS wird dies jedoch praktisch nur selten bemerkt, da eine Lesesperre für eine Zeile über eine äußerst kurze Zeitspanne aufrechterhalten wird. Wenn die Daten angezeigt werden, ist die Sperre bereits wieder freigegeben. Lesevorgänge können Schreibvorgänge nur in Anwendungen blockieren, in denen im DBMS ein Cursor geöffnet und jeweils eine Zeile abgerufen wird und anschließend die Ergebnisse im Rahmen der Verarbeitung durchlaufen werden. In einem solchen Fall setzen DB2 und Informix Sperren und erhalten diese aufrecht, solange die Ergebnisse verarbeitet werden.

PostgreSQL

Schreibvorgänge blockieren Schreibvorgänge: In PostgreSQL kann eine Zeile erst aktualisiert werden, wenn die erste Transaktion, mit der eine Änderung an der Zeile vorgenommen wurde, in der Datenbank festgeschrieben oder zurückgesetzt wurde. Wenn zwei Benutzer versuchen, dasselbe Feature gleichzeitig zu bearbeiten, sperrt der erste Benutzer die Zeile für Aktualisierungen. Andere Benutzer können die Zeile erst bearbeiten, wenn dieser Benutzer sie speichert und somit die Änderungen in der Datenbank festschreibt oder die Editiersitzung ohne Speichern beendet, wodurch alle in dieser Editiersitzung vorgenommenen Bearbeitungen rückgängig gemacht werden.

Während der Sperre des Features versucht der zweite Benutzer, dasselbe Feature zu bearbeiten. Die ArcMap-Sitzung des zweiten Benutzers wartet bis zur Freigabe der Sperren, wobei die vertraute Sanduhr angezeigt wird. Die Sanduhr wird angezeigt, bis der erste Benutzer die Änderungen speichert (die Änderungen in der Datenbank festschreibt) oder die Editiersitzung ohne Speichern der Änderungen beendet (die Bearbeitungen verwirft). Anschließend wird die Sanduhr auf dem Bildschirm des zweiten Benutzers ausgeblendet. Der zweite Benutzer kann nun seine Bearbeitungen ausführen. (Dies bedeutet allerdings, dass die Änderungen des zweiten Benutzers die des ersten überschreiben.)

Schreibvorgänge blockieren keine Lesevorgänge: Wenn Sie die Steuerung der Nebenläufigkeit mehrerer Versionen (Multiversion Concurrency Control, MVCC) von PostgreSQL verwenden, also das standardmäßige und empfohlene Verhalten der Datenbank, blockieren Benutzertransaktionen, die in die Datenbank schreiben, keine Leserabfragen der Datenbank. Dies gilt für den Isolationsgrad READ COMMITTED in der Datenbank und für den Isolationsgrad SERIALIZABLE.

Lesevorgänge blockieren keine Schreibvorgänge: Unabhängig vom für die Datenbank festgelegten Isolationsgrad blockieren Lesevorgänge keine Daten.

SQL Server

ArcGIS legt den Isolationsgrad vor jeder Transaktion in einer SQL Server-Geodatabase auf READ UNCOMMITTED fest. Im Folgenden werden mögliche Probleme mit der Nebenläufigkeit beschrieben, die mit ArcGIS auftreten können. Weitere Informationen zum Isolationsgrad READ UNCOMMITTED finden Sie in der SQL Server-Dokumentation.

Schreibvorgänge blockieren Schreibvorgänge: Schreibvorgänge blockieren Schreibvorgänge in SQL Server ähnlich wie in Oracle. Weitere Informationen hierzu finden Sie in den Erläuterungen zu Oracle.

Schreibvorgänge blockieren keine Lesevorgänge: Da ArcGIS vor jeder Transaktion den Isolationsgrad auf READ UNCOMMITTED festlegt, blockieren Schreibvorgänge in SQL Server-Geodatabases keine Lesevorgänge. Wenn jedoch einige Benutzer Daten ändern und andere Benutzer dieselben Daten lesen, lesen letztere möglicherweise Daten, die geändert, aber noch nicht festgeschrieben wurden. Dies wird als "Dirty Read" bezeichnet, und in Abfragen kann Folgendes zurückgegeben werden:

• Ungenaue Datenwerte
• Keine Rückgabe von Daten, obwohl Daten vorhanden sind
• Rückgabe doppelter Daten, obwohl sie nicht vorhanden sind

Lesevorgänge blockieren keine Schreibvorgänge: Da ArcGIS vor jeder Transaktion den Isolationsgrad auf READ UNCOMMITTED festlegt, blockieren Lesevorgänge in SQL Server-Geodatabases keine Schreibvorgänge.

Verhindern von Problemen mit Nebenläufigkeit

Erfreulicherweise gibt es Möglichkeiten, Probleme mit der Nebenläufigkeit zu minimieren:

Entwerfen von Anwendungen und Workflows unter Berücksichtigung von Sperren: Anforderungen müssen häufig auf die Freigabe von Sperren warten, weil die entsprechenden Anwendungen oder Workflows schlecht entworfen wurden. Stellen Sie beim Entwickeln einer Anwendung oder eines Workflows sicher, dass Sperren in geordneter Weise angefordert werden. Dies können Sie erreichen, indem Sie die Folge der Aktualisierungen für alle Tabellen standardisieren. Auf diese Weise sollten Deadlocks verhindert werden. Zum Verringern der Haltezeit von Sperren empfiehlt es sich, alle Datenänderungsanforderungen am Ende jeder Einheit der Anwendungslogik bzw. des Workflows auszugeben, mit der eine Transaktion ausgeführt wird.

Festlegen des entsprechenden Isolationsgrades (Oracle, DB2, Informix): Der Isolationsgrad wirkt sich auf den Zeitraum aus, für den eine Transaktion Daten sperrt. Je höher der Isolationsgrad, desto länger erhält die Transaktion die Sperre aufrecht. Je länger die Transaktion die Sperre aufrechterhält, desto höher ist die Datenintegrität, jedoch auf Kosten der (abnehmenden) Nebenläufigkeit. Wenn dies für die Anwendung akzeptabel ist, können Sie den Isolationsgrad verringern, um die Nebenläufigkeit zu verbessern.

Registrierung von Daten als versioniert: Verbessern Sie die Nebenläufigkeit, indem Sie Daten mit der Option zum Verschieben von Änderungen in die Basistabelle als versioniert registrieren. Auf diese Weise können Benutzer die Datenverwaltung mit Anwendungen fortsetzen, die nicht ArcGIS verwenden. Benutzern der Anwendungen ArcGIS und ArcObjects, die andernfalls Probleme mit der Nebenläufigkeit verursachen würden bzw. von solchen betroffen wären, wird so jedoch die Möglichkeit gegeben, Versionen der Daten zu bearbeiten und zu verwalten. Wenn ein Benutzer eine Version bearbeitet, werden keine Sperren gesetzt. Die Bearbeitung der Daten erfolgt somit in vollständiger Isolation von anderen Benutzern.

Datenbanksperren bilden ein komplexes Thema. Außerdem werden Sperren von jedem DBMS anders behandelt. Daher müssen Sie das Verhalten Ihres DBMS prüfen, um zu ermitteln, auf welcher Ebene die Sperren gesetzt, wie Isolationsgrade festgelegt und wie Timeouts für Sperren und Deadlocks behandelt werden sollen.