Lease Blob

Der Lease Blob Vorgang erstellt und verwaltet eine Sperre für ein Blob für Schreib- und Löschvorgänge. Die Sperrdauer kann 15 bis 60 Sekunden betragen oder unendlich sein. In Versionen vor 2012-02-12 beträgt die Sperrdauer 60 Sekunden.

Sie können den Lease Blob Vorgang in einem der folgenden Modi aufrufen:

• Acquire, um eine neue Lease anzufordern.

• Renew, um eine vorhandene Lease zu verlängern.

• Change, um die ID einer vorhandenen Lease zu ändern.

• Release, um die Lease frei zu geben, wenn sie nicht mehr benötigt wird, damit ein anderer Client sofort eine Lease für das Blob erwerben kann.

• Break, um die Lease zu beenden, aber sicherstellen, dass ein anderer Client erst dann eine neue Lease erwerben kann, wenn der aktuelle Leasezeitraum abgelaufen ist.

Anforderung

Sie können die Lease Blob Anforderung wie folgt erstellen. HTTPS wird empfohlen. Ersetzen Sie myaccount durch den Namen Ihres Speicherkontos.

Emulierter Speicherdienst-URI

Wenn Sie eine Anforderung an den emulierten Speicherdienst stellen, geben Sie den Emulatorhostnamen und Azure Blob Storage Port als 127.0.0.1:10000an, gefolgt vom Namen des emulierten Speicherkontos.

Weitere Informationen finden Sie unter Verwenden des Azurite-Emulators für die lokale Azure Storage-Entwicklung.

URI-Parameter

Sie können den folgenden zusätzlichen Parameter für den Anforderungs-URI angeben.

Anforderungsheader

In der folgenden Tabelle werden erforderliche und optionale Anforderungsheader beschrieben.

Dieser Vorgang unterstützt auch die Verwendung von bedingten Headern zum Ausführen des Vorgangs, nur wenn eine angegebene Bedingung erfüllt ist. Weitere Informationen finden Sie unter Angeben von bedingten Headern für Blob Storage-Vorgänge.

Anforderungstext

Keine.

Beispiel für eine Anforderung

Die folgende Beispielanforderung zeigt, wie eine Lease abgerufen wird:

  
Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=lease HTTP/1.1  
  
Request Headers:  
x-ms-version: 2015-02-21  
x-ms-lease-action: acquire  
x-ms-lease-duration: -1  
x-ms-proposed-lease-id: 1f812371-a41d-49e6-b123-f4b542e851c5  
x-ms-date: <date>  
Authorization: SharedKey testaccount1:esSKMOYdK4o+nGTuTyeOLBI+xqnqi6aBmiW4XI699+o=  
  

Antwort

Die Antwort enthält den HTTP-Statuscode und einen Satz von Antwortheadern.

Statuscode

Die für Leasevorgänge zurückgegebenen Codes für den Erfolgsstatus lauten wie folgt:

• Acquire: Bei einem erfolgreichen Vorgang wird der Statuscode 201 (Erstellt) zurückgegeben.

• Renew: Bei einem erfolgreichen Vorgang wird der Statuscode 200 (OK) zurückgegeben.

• Change: Bei einem erfolgreichen Vorgang wird der Statuscode 200 (OK) zurückgegeben.

• Release: Bei einem erfolgreichen Vorgang wird der Statuscode 200 (OK) zurückgegeben.

• Break: Ein erfolgreicher Vorgang gibt den Statuscode 202 (Akzeptiert) zurück.

Informationen zu status Codes finden Sie unter Status- und Fehlercodes.

Antwortheader

Die Antwort für diesen Vorgang umfasst die folgenden Header. Die Antwort kann auch zusätzliche HTTP-Standardheader enthalten. Alle Standardheader entsprechen der HTTP/1.1-Protokollspezifikation.

Antworttext

Keine.

Beispiel für eine Antwort

Im Folgenden finden Sie eine Beispielantwort für eine Anforderung zum Abrufen einer Lease:

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-request-id: cc6b209a-b593-4be1-a38a-dde7c106f402  
x-ms-version: 2015-02-21  
x-ms-lease-id: 1f812371-a41d-49e6-b123-f4b542e851c5  
Date: <date>  
  

Authorization

Beim Aufrufen eines Datenzugriffsvorgangs in Azure Storage ist eine Autorisierung erforderlich. Sie können den Lease Blob Vorgang wie unten beschrieben autorisieren.

Hinweise

Eine Lease für ein BLOB stellt den exklusiven Zugriff zum Schreiben und Löschen für das BLOB bereit. Zum Schreiben in ein BLOB mit einer aktiven Lease muss ein Client die aktive Lease-ID in die Schreibanforderung einschließen. Die Lease wird für die Dauer gewährt, die beim Erwerb der Lease angegeben wird. Diese Dauer kann zwischen 15 und 60 Sekunden oder eine unendliche Dauer betragen.

Wenn ein Client eine Lease abruft, wird eine Lease-ID zurückgegeben. Blob Storage generiert eine Lease-ID, wenn keine in der Abrufanforderung angegeben ist. Der Client kann diese Lease-ID verwenden, um die Lease zu verlängern, seine Lease-ID zu ändern oder die Lease freizugeben.

Wenn eine Lease aktiv ist, muss die Lease-ID in der Anforderung für die folgenden Vorgänge eingeschlossen werden:

• Put Blob

• Set Blob Metadata

• Set Blob Properties

• Delete Blob

• Put Block

• Put Block List

• Put Page

• Append Block

• Kopieren eines Blobs (Lease-ID für Zielblob erforderlich)

Wenn die Lease-ID nicht enthalten ist, schlagen diese Vorgänge für ein geleastes Blob mit 412 – Precondition failedfehl.

Die folgenden Vorgänge sind für ein geleastes Blob erfolgreich, ohne die Lease-ID zu enthalten:

• Get Blob

• Get Blob Metadata

• Get Blob Properties

• Get Block List

• Get Page Ranges

• Auflisten von Blobs

• Kopieren eines Blobs (Für Quellblob ist keine Lease-ID erforderlich.)

• Leaseblob (REST-API) (Keine Lease-ID erforderlich für x-ms-lease-action: break.)

Es ist nicht erforderlich, die Lease-ID für Vorgänge in GET einem Blob einzuschließen, das über eine aktive Lease verfügt. Alle GET Vorgänge unterstützen jedoch einen bedingten Leaseparameter, wobei der Vorgang nur fortgesetzt wird, wenn die in der Anforderung enthaltene Lease-ID gültig ist.

Alle Containervorgänge sind für einen Container zulässig, der Blobs mit einer aktiven Lease beinhaltet, einschließlich Container löschen. Daher kann ein Container auch dann gelöscht werden, wenn darin enthaltene Blobs über aktive Leases verfügen. Verwenden Sie den Vorgang Container leasen, um die Berechtigungen zum Löschen eines Containers zu steuern.

Leasestatus

Im folgenden Diagramm werden die fünf Statusangaben einer Lease sowie die Befehle oder Ereignisse gezeigt, die Leasestatusänderungen verursachen.

Eine Lease kann sich in einem dieser Zustände befinden, je nachdem, ob die Lease gesperrt oder entsperrt ist und ob die Lease in diesem Zustand erneuerbar ist. Die im vorherigen Diagramm gezeigten Leaseaktionen verursachen Zustandsübergänge.

• Available: Die Lease ist entsperrt und kann erworben werden. Zulässige Aktion: acquire.

• Leased: Die Lease ist gesperrt. Zulässige Aktionen: acquire (nur dieselbe Lease-ID), renew, change, release und break.

• Expired: Die Leasedauer ist abgelaufen. Zulässige Aktionen: acquire, renew, release und break.

• Breaking: Die Lease wurde unterbrochen, aber die Lease bleibt weiterhin gesperrt, bis der Pausenzeitraum abgelaufen ist. Zulässige Aktionen: release und break.

• Broken: Die Lease wurde unterbrochen, und der Pausenzeitraum ist abgelaufen. Zulässige Aktionen: acquire, release und break.

Nach Ablauf einer Lease wird die Lease-ID von Blob Storage verwaltet, bis das Blob geändert oder erneut geleast wird. Ein Client kann versuchen, die Lease mithilfe seiner abgelaufenen Lease-ID zu verlängern oder freizugeben. Wenn der Vorgang erfolgreich ist, bedeutet dies, dass das Blob seit der letzten Gültigkeit der Lease-ID nicht geändert wurde.

Wenn der Client versucht, eine Lease mit der vorherigen Lease-ID zu erneuern oder freizugeben, und die Anforderung schlägt fehl, wurde das Blob erneut geändert oder geleast, da die Lease des Clients zuletzt aktiv war. Der Client muss dann eine neue Lease für das BLOB abrufen.

Wenn eine Lease abläuft und nicht explizit freigegeben wird, muss ein Client möglicherweise bis zu einer Minute warten, bevor eine neue Lease für das Blob abgerufen werden kann. Der Client kann die Lease jedoch sofort mit seiner Lease-ID verlängern, wenn das Blob nicht geändert wurde.

Beachten Sie, dass eine Lease für ein Blob Momentaufnahme nicht gewährt werden kann, da Momentaufnahmen schreibgeschützt sind. Das Anfordern einer Lease für eine Momentaufnahme erzeugt Statuscode 400 (Ungültige Anforderung).

Die -Eigenschaft des Blobs Last-Modified-Time wird nicht durch Aufrufe von Lease Blobaktualisiert.

In den folgenden Tabellen werden die Ergebnisse von Aktionen für BLOBs mit Leases in verschiedenen Leasestatus aufgelistet. Die Buchstaben (A), (B) und (C) stellen Lease-IDs dar, und (X) stellt eine von Blob Storage generierte Lease-ID dar.

Ergebnisse der Nutzungsversuche für BLOBs nach Leasestatus

Ergebnisse von Leasevorgängen für BLOBs nach Leasestatus

Änderungen am Leaseblob, die in Version 2012-02-12 eingeführt wurden

Die folgende Liste gibt Änderungen am Verhalten an, die Lease Blob in Version 2012-02-12 eingeführt wurden.

• Ein Aufruf von zum Lease Blob Abrufen einer Lease muss jetzt einen Leasedauerheader enthalten. Wenn Sie versuchen, eine Lease zu erwerben, ohne eine Leasedauer anzugeben, gibt der Dienst zurück 400 Bad Request – Missing required header.

• Nach der Freigabe einer Lease können Sie diese nicht mehr verlängern. Wenn Sie dies versuchen, gibt der Dienst zurück 409 Conflict – The lease ID specified did not match the lease ID for the blob. Anwendungen, die "release" aufgerufen und dann "renew" aufgerufen haben, müssen jetzt den ETag aus dem Releaseaufruf speichern. Dann müssen Anwendungen acquire mit einem bedingten If-Match Header aufrufen, um die Lease nur dann abzurufen, wenn das Blob unverändert ist.

• Nach der Freigabe einer Lease können Sie diese nicht mehr unterbrechen. Wenn Sie dies versuchen, gibt der Dienst zurück 409 Conflict – There is currently no lease on the blob.

• Sie können eine Lease, die gerade unterbrochen wird oder unterbrochen ist, jetzt unterbrechen, sodass Unterbrechungsvorgänge idempotent sind. In früheren Versionen schlug dieser Vorgang mit 409 Conflict – The lease has already been broken and cannot be broken again fehl. Diese Änderung ermöglicht es Ihnen, die Dauer einer Unterbrechung zu verkürzen. Wenn Sie eine Lease unterbrechen, die sich im Unterbrechungszustand befindet, und eine kürzere Dauer als der verbleibende Pausenzeitraum enthalten, wird Ihre kürzere Dauer verwendet.

Abrechnung

Preisanforderungen können von Clients stammen, die Blob Storage-APIs verwenden, entweder direkt über die Blob Storage-REST-API oder aus einer Azure Storage-Clientbibliothek. Für diese Anforderungen fallen Gebühren pro Transaktion an. Die Art der Transaktion wirkt sich auf die Belastung des Kontos aus. Beispielsweise werden Lesetransaktionen in eine andere Abrechnungskategorie als das Schreiben von Transaktionen angewendet. Die folgende Tabelle zeigt die Abrechnungskategorie für Lease Blob Anforderungen basierend auf dem Speicherkontotyp:

Weitere Informationen

new-blob-lease-features-infinite-leases-smaller-lease-times-and-more.aspx)
Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Blob Storage-Fehlercodes
Lease Container