Zum Hauptinhalt springen

7. Write Lock (Schreibsperre)

Dieser Abschnitt beschreibt die Schreibsperre (Write Lock), den einzigen in dieser Spezifikation definierten Sperrtyp. Eine Schreibsperre ist eine Sperre, die dem Sperrinhaber das Recht gewährt, die Ressource zu ändern. Der Sperrinhaber ist der Prinzipal, der die Sperre erstellt hat.

7.1 Write Locks and Properties (Schreibsperren und Eigenschaften)​

Obwohl diejenigen ohne Schreibsperre den Inhalt einer Ressource nicht ändern dürfen, können (MAY) sie die Dead-Eigenschaften der Ressource ändern. Dies ermöglicht es beispielsweise einem Prinzipal, Kommentare zu einer gesperrten Ressource hinzuzufügen, ohne Schreibzugriff zu benötigen.

Live-Eigenschaften haben typischerweise eine vom Server erzwungene Semantik. Der Server hat daher das Ermessen darüber, ob und wie Änderungen an Live-Eigenschaften erlaubt werden, wenn eine Ressource gesperrt ist. Beispielsweise kann (MAY) ein Server die Änderung von Live-Eigenschaften auch dann erlauben, wenn eine Ressource gesperrt ist.

7.2 Avoiding Lost Updates (Vermeidung verlorener Updates)​

Der Zweck von Schreibsperren besteht darin, verlorene Updates zu verhindern. Ein verlorenes Update tritt auf, wenn mehrere Prinzipale versuchen, eine Ressource ohne Koordination zu ändern, was dazu führt, dass die Änderungen eines oder mehrerer Prinzipale durch nachfolgende Updates überschrieben werden.

Schreibsperren bieten einen Serialisierungsmechanismus: Nur der Sperrinhaber kann die gesperrte Ressource ändern. Dies verhindert das Problem verlorener Updates, indem sichergestellt wird, dass Änderungen sequenziell und nicht gleichzeitig erfolgen.

Beispiel für verlorenes Update-Szenario (ohne Sperre):

  1. Benutzer A ruft Ressourcenversion 1 ab
  2. Benutzer B ruft Ressourcenversion 1 ab
  3. Benutzer A ändert und speichert → erstellt Version 2
  4. Benutzer B ändert (basierend auf Version 1) und speichert → erstellt Version 3, überschreibt die Änderungen von A

Mit Schreibsperre:

  1. Benutzer A sperrt die Ressource
  2. Benutzer B versucht zu ändern → erhält 423 Locked-Fehler
  3. Benutzer A ändert und entsperrt
  4. Benutzer B kann jetzt sperren und ändern

7.3 Write Locks and Unmapped URLs (Schreibsperren und nicht zugeordnete URLs)​

Eine erfolgreiche LOCK-Anfrage auf einer nicht zugeordneten URL erstellt eine leere Ressource, die gesperrt ist. Dieser Mechanismus ermöglicht es Clients, eine URL zu reservieren, bevor der Ressourceninhalt erstellt wird.

Wenn eine gesperrte leere Ressource erstellt wird:

  • Die Ressource hat keinen Inhalt (Entität mit Nulllänge)
  • Die Ressource ist mit der angegebenen Sperre gesperrt
  • Ein nachfolgendes PUT oder MKCOL kann der Ressource Inhalt hinzufügen
  • Das Sperrtoken muss mit der PUT- oder MKCOL-Anfrage übermittelt werden

Dieser „Lock-null-Ressourcen"-Mechanismus wird in Anhang D detailliert beschrieben.

7.4 Write Locks and Collections (Schreibsperren und Sammlungen)​

Eine Schreibsperre auf einer Sammlung sperrt die Sammlungsressource selbst und verhindert Änderungen an der Mitgliedschaft der Sammlung (Hinzufügen oder Entfernen interner Mitglieder).

Wenn eine Sperre mit unendlicher Tiefe auf eine Sammlung angewendet wird:

  • Die Sammlung selbst wird gesperrt
  • Alle internen Mitglieder werden gesperrt
  • Alle Nachfolgerressourcen werden rekursiv gesperrt
  • Neue Mitglieder, die der Sammlung hinzugefügt werden, werden automatisch gesperrt

Sperrvererbung: Wenn eine neue Ressource zu einer gesperrten Sammlung (mit unendlicher Tiefe) hinzugefügt wird, erbt die neue Ressource die Sperre von der übergeordneten Sammlung.

7.5 Write Locks and the If Request Header (Schreibsperren und der If-Request-Header)​

Clients übermitteln Sperrtokens mit dem If-Request-Header. Dieser Header ermöglicht die bedingte Ausführung von Methoden basierend auf dem Vorhandensein von Sperrtokens.

Die If-Header-Syntax unterstützt:

  • Einzelne Sperrtokens
  • Mehrere Sperrtokens (für mehrere Sperren)
  • Markierte Listen (Zuordnung von Tokens zu bestimmten URLs)
  • NOT-Bedingungen (Anforderung der Abwesenheit von Sperren)

7.5.1 Example - Write Lock and COPY (Beispiel - Schreibsperre und COPY)​

COPY /source HTTP/1.1
Host: example.com
Destination: http://example.com/destination
If: `http://example.com/destination` (<opaquelocktoken:token123>)

Diese Anfrage kopiert /source nach /destination, aber nur, wenn der Client das Sperrtoken für /destination hält.

7.5.2 Example - Deleting a Member of a Locked Collection (Beispiel - Löschen eines Mitglieds einer gesperrten Sammlung)​

DELETE /folder/file.txt HTTP/1.1
Host: example.com
If: `http://example.com/folder/` (<opaquelocktoken:folder-token>)

Um ein Mitglied einer gesperrten Sammlung zu löschen, muss der Client das Sperrtoken für die Sammlung übermitteln.

7.6 Write Locks and COPY/MOVE (Schreibsperren und COPY/MOVE)​

Die COPY-Methode erstellt eine neue Ressource am Ziel. Die neue Ressource wird NICHT automatisch gesperrt, selbst wenn die Quelle gesperrt war. Sperren werden nicht kopiert.

Die MOVE-Methode ist semantisch äquivalent zu COPY gefolgt von DELETE. Die Sperre der Quelle wird entfernt, wenn die Ressource verschoben wird. Das Ziel wird nicht automatisch gesperrt.

Wenn das Ziel eines COPY oder MOVE gesperrt ist, muss der Client das entsprechende Sperrtoken übermitteln, um das Ziel zu überschreiben.

7.7 Refreshing Write Locks (Aktualisierung von Schreibsperren)​

Sperren haben endliche Lebensdauern. Um ein vorzeitiges Ablaufen der Sperre zu verhindern, können Clients Sperren durch Übermittlung einer LOCK-Anfrage mit folgenden Eigenschaften aktualisieren:

  • Dasselbe Sperrtoken im If-Header
  • Kein Request-Body (oder ein leeres lockinfo-Element)

Der Server antwortet mit dem neuen Timeout-Wert. Die Sperrakt ualisierung ermöglicht langfristige Bearbeitungssitzungen ohne Sperrablauf.

Beispiel für Sperraktualisierung:

LOCK /resource HTTP/1.1
Host: example.com
If: (<opaquelocktoken:token123>)
Timeout: Second-3600

Der Server verlängert den Sperr-Timeout und gibt die neue Ablaufzeit zurück.

Letztes Update am