IT-Academy Logo
Sign Up Login Help
Home - Programmieren - Datenbanken - Sperrmechanismen



Sperrmechanismen

Damit Transaktionen nach den ACID-Prinzip ablaufen können (siehe Artikel über Transaktionen) und die somit im Artikel über Synchronisationsproblemedie geschilderten Probleme wie "Lost Updates", "Dirty Reads" usw. gar nicht auftreten, müssen Datenobjekte gesperrt werden können.


Autor: Patrick Bucher (paedubucher)
Datum: 21-07-2007, 11:41:14
Referenzen: keine
Schwierigkeit: Fortgeschrittene
Ansichten: 3864x
Rating: 7 (1x bewertet)

Hinweis:

Für den hier dargestellte Inhalt ist nicht der Betreiber der Plattform, sondern der jeweilige Autor verantwortlich.
Falls Sie Missbrauch vermuten, bitten wir Sie, uns unter missbrauch@it-academy.cc zu kontaktieren.

[Druckansicht] [Als E-Mail senden] [Kommentar verfassen]



Eine Sperre bietet einer Transaktion exklusiven Zugriff auf einen Teil der Datenbank. Bevor eine Transaktion ihre Operationen ausführen kann, müssen die betreffenden Datenobjekte gesperrt werden. Erst dann können die Operationen einer Transaktion sequenziell abgearbeitet werden. Am Ende einer Transaktion (ganz egal, ob diese durch COMMIT oder ROLLBACK beendet wurde), müssen diese Sperren dann wieder entfernt werden, damit andere Transaktionen ebenfalls mit diesen Datenobjekten arbeiten können.

Moderne Datenbanksysteme verwalten Sperren automatisch, sodass der Programmierer sich nicht um diese Feinheiten kümmern muss.

Granularität

Unter dem Begriff Granularität versteht man, auf welcher Ebene die Daten von einer Transaktion gesperrt werden. Dazu gibt es verschiedene Möglichkeiten, welche im Folgenden einzeln betrachtet werden:

  • Sperren auf Datenbankebene
    • Eine Transaktion sperrt die gesamte Datenbank, sodass keine andere Transaktion irgendwelche Operationen auf die Datenbank anwenden kann, solange die eine Transaktion die Datenbank nicht wieder freigegeben hat.
  • Sperren auf Tabellenebene
    • Eine Transaktion sperrt nur die Tabellen, auf die sie auch wirklich zugreifen muss.
    • Alle anderen Tabellen können weiterhin von anderen Transaktionen verwendet werden.
  • Sperren auf Seitenebene
    • Datenobjekte werden auf einem Datenbanksystem in sog. "Seiten" abgelegt. Eine Seite enthält einen Teil eines Datensatzes, einen Datensatz oder mehrere Datensätze.
    • Eine Transaktion sperrt nur die Seiten, auf deren Datensätze sie auch wirklich zugreifen muss.
    • Datensätze der gleichen Tabelle, die sich jedoch auf einer anderen Seite befinden, können weiterhin von anderen Transaktionen bearbeitet werden.
  • Sperren auf Datensatzebene
    • Eine Transaktion sperrt nur die Datensätze, die sie auch wirklich bearbeiten muss.
    • Auf alle anderen Datensätze kann weiterhin von anderen Transaktionen aus zugegriffen werden.
  • Sperren auf Feldebene
    • Eine Transaktion sperrt nur die Felder eines Datensatzes, auf die auch wirklich zugegriffen werden muss.
    • Dies ist die flexibelste aller Sperren, da in diesem Fall sogar mehrere Transaktionen gleichzeitig auf den gleichen Datensatz zugreifen können.

Die Sperre auf die ganze Datenbank ist für normale Anwendungen viel zu restriktiv. Auch die Sperre auf eine ganze Tabelle bremst das System oftmals unnötig aus, da die Transaktionen möglicherweise auf ganz unterschiedliche Bereiche der Tabelle zugreifen müssen.

Einen guten Kompromiss stellt die Sperre auf Seitenebene dar.

Die Sperre auf Datensatzebene stellt schon einen beträchtlichen Overhead dar, bei der Sperre auf Feldebene muss sich das Datenbankverwaltungssystem für jedes Feld merken, ob und von welcher Transaktion es gesperrt ist.

Sperrtypen

Die Granularität sagt aus, auf welcher Ebene Datenobjekte gesperrt werden. Es gibt aber auch verschiedene Möglichkeiten, wie diese Sperren errichtet werden.

Binäre Sperren

Bei der binären Sperre ist ein Datenobjekt entweder gesperrt, oder nicht gesperrt. Möchte eine Transaktion, egal ob lesend oder schreibend, auf ein Datenobjekt zugreifen, so wird dieses gesperrt. Während dieser Sperre dürfen andere Transaktionen weder lesend, noch schreibend auf die gesperrten Datenobjekte zugreifen.

Die binäre Sperre ist sehr restriktiv. Sie erlaubt es nicht, dass mehrere Transaktionen gleichzeitig lesend auf die gleichen Datenobjekte zugreifen können, obwohl dies keinerlei negative Auswirkung auf die Datenkonsistenz haben kann.

Exklusive und nicht-exklusive Sperren

Ein weiterer Ansatz ist die Unterscheidung in exklusive und nicht exklusive Sperren. Ein Datenobjekt kann dabei drei Zustände haben:

  1. Nicht gesperrt
    • Transaktionen können exklusive oder nicht-exklusive Sperren auf diese Datenobjekte anlegen.
  2. Exklusiv gesperrt
    • Diese Sperre wird errichtet, wenn schreibend auf Datenobjekte zugegriffen werden muss.
    • Ist ein Datenobjekt exklusiv gesperrt, dürfen keine anderen Sperren darauf eingerichtet werden (weder exklusive, noch nicht-exklusive).
  3. Nicht-exklusiv gesperrt
    • Diese Sperre wird errichtet, wenn nur lesend auf Datenobjekte zugegriffen werden muss.
    • Ist ein Datenobjekt nicht-exklusiv gesperrt, so dürfen darauf beliebig weitere nicht-exklusive Sperren eingerichtet werden, jedoch keine exklusiven.

Diese Art des Lockings ist viel flexibler als die binären Sperren und wird daher auch häufiger eingesetzt.

Deadlocks

Möchten zwei Transaktionen auf die gleiche Ressource eine Sperre errichten und tun sie dies in verschiedener Reihenfolge, so kommt es zu einem Stillstand. Dieser Stillstand wird als Deadlock bezeichnet.

Beispiel: Transaktion A und Transaktion B möchten die Tabellen "customer" und "address" sperren, tun dies aber in unterschiedlicher Reihenfolge.

  • Transaktion A sperrt die Tabelle "customer"
  • Transaktion B sperrt die Tabelle "address"
  • Transaktion A möchte nun ebenfalls die Tabelle "address" sperren
    • "address" ist jedoch schon durch Transaktion B gesperrt
  • Transaktion B möchte nun ebenfalls die Tabelle "customer" sperren
    • "customer" ist jedoch schon durch Transaktion A gesperrt

Die beiden Transaktionen warten nun so lange, bis die jeweils andere Transaktion die Tabelle wieder freigegeben hat. Dies ist jedoch nicht möglich, da keine der beiden Transaktionen abgearbeitet werden kann, bevor die andere ihre Sperren nicht wieder aufgehoben hat. Die Transaktionen stehen also still -- ein klassischer Deadlock.

Verhinderung von Deadlocks

Es gibt drei Möglichkeiten, wie Deadlocks aufgehoben oder verhindert werden können:

  1. Timeout
    • Muss eine Transaktion eine bestimmte Zeit auf eine Ressource warten (z.B. länger als 5 Sekunden), wird diese abgebrochen.
    • Die andere Transaktion kann ihre Sperren nun errichten und so erfolgreich abgearbeitet werden.
  2. Eine Transaktion abbrechen
    • Sobald das Datenbanksystem einen Deadlock erkennt, sucht es sich unter den involvierten Transaktionen ein Opfer. Diese Transaktion wird dann abgebrochen.
    • Die andere Transaktion kann mit der Arbeit fortfahren.
  3. Die Sperren werden mit dem 2-Phasen Locking erstellt
    • Eine Transaktion wird in drei Phasen aufgeteilt:
      1. Wachstumsphase: Erstellung der Sperren
      2. Gesperrte Phase: Die Transaktion kann ihre Operationen durchführen
      3. Schrumpfphase: Die Sperren werden wieder abgebaut
    • Die Transaktion kann somit nur Operationen ausführen, wenn sie alle benötigten Datenobjekte sperren konnte.
    • Die Datenobjekte werden in umgekehrter Reihenfolge zur Sperrung wieder freigegeben.
    • Somit können zwei Transaktionen keine Sperren besitzen, die in Konflikt zueinander stehen.
    • Es werden keine Daten verändert, bevor nicht sämtliche Sperren erfolgreich errichtet werden konnten.


[back to top]



Userdaten
User nicht eingeloggt

Gesamtranking
Werbung
Datenbankstand
Autoren:04508
Artikel:00815
Glossar:04116
News:13565
Userbeiträge:16552
Queueeinträge:06246
News Umfrage
Ihre Anforderungen an ein Online-Zeiterfassungs-Produkt?
Mobile Nutzung möglich (Ipone, Android)
Externe API Schnittstelle/Plugins dritter
Zeiterfassung meiner Mitarbeiter
Exportieren in CSV/XLS
Siehe Kommentar



[Results] | [Archiv] Votes: 1154
Comments: 0