Freigeben über

Lease Blob

  • Artikel

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.

Wichtig

Ab Version 2012-02-12 weicht das Verhalten des Vorgangs Lease Blob gelegentlich vom Verhalten in früheren Versionen ab. In früheren Versionen konnten Sie beispielsweise eine Lease nach der Veröffentlichung verlängern. Ab Version 2012-02-12 schlägt diese Leaseanforderung fehl, aber Aufrufe, die ältere Versionen von Lease Blob verwenden, sind weiterhin erfolgreich. Eine Liste der Änderungen am Verhalten dieses Vorgangs finden Sie im Abschnitt "Hinweise" weiter unten in diesem Artikel.

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 freizugeben, 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 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.

PUT-Methodenanforderungs-URI HTTP-Version
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=lease HTTP/1.1

Emulierter Speicherdienst-URI

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

PUT-Methodenanforderungs-URI HTTP-Version
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=lease HTTP/1.0

HTTP/1.1

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.

Parameter BESCHREIBUNG
timeout Optional. Der timeout-Parameter wird in Sekunden angegeben. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blob Storage-Vorgänge.

Anforderungsheader

In der folgenden Tabelle werden erforderliche und optionale Anforderungsheader beschrieben.

Anforderungsheader BESCHREIBUNG
Authorization Erforderlich. Gibt das Autorisierungsschema, den Kontonamen und die Signatur an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
Date oder x-ms-date Erforderlich. Gibt die koordinierte Weltzeit (Coordinated Universal Time, UTC) für die Anforderung an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
x-ms-version Optional. Gibt die Version des für die Anforderung zu verwendenden Vorgangs an. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste.
x-ms-lease-id: <ID> Erforderlich, um die Lease zu verlängern, zu ändern oder freizugeben.

Sie können den Wert von x-ms-lease-id in einem beliebigen gültigen GUID-Zeichenfolgenformat angeben. Eine Liste gültiger Formate finden Sie unter Guid-Konstruktor (String).
x-ms-lease-action: <acquire ¦ renew ¦ change ¦ release ¦ break> acquire: Fordert eine neue Lease an. Wenn das Blob keine aktive Lease aufweist, erstellt Blob Storage eine Lease für das Blob und gibt eine neue Lease-ID zurück. Wenn das Blob über eine aktive Lease verfügt, können Sie nur mithilfe der aktiven Lease-ID eine neue Lease anfordern. Sie können jedoch einen neuen x-ms-lease-durationangeben, einschließlich einer negativen (-1) für eine Lease, die nie abläuft.

renew: Verlängert die Lease. Sie können die Lease verlängern, wenn die in der Anforderung angegebene Lease-ID der dem Blob zugeordneten entspricht. Beachten Sie, dass die Lease auch dann verlängert werden kann, wenn sie abgelaufen ist, solange das Blob seit Ablauf dieser Lease nicht mehr geändert oder geleast wurde. Beim Verlängern einer Lease wird die Leasedauer zurückgesetzt.

change: Version 2012-02-12 und höher. Ändert die Lease-ID einer aktiven Lease. Ein change muss die aktuelle Lease-ID in x-ms-lease-idund eine neue Lease-ID in x-ms-proposed-lease-identhalten.

release: Gibt die Lease frei. Sie können die Lease freigeben, wenn die in der Anforderung angegebene Lease-ID der dem Blob zugeordneten entspricht. Durch das Freigeben der Lease kann ein anderer Client sofort die Lease für das Blob erwerben, sobald die Veröffentlichung abgeschlossen ist.

break: Unterbricht die Lease, wenn das BLOB über eine aktive Lease verfügt. Nachdem ein Lease unterbrochen wurde, kann sie nicht mehr verlängert werden. Die Lease kann mit jeder autorisierten Anforderung unterbrochen werden. In der Anforderung muss keine übereinstimmende Lease-ID angegeben werden. Wenn eine Lease unterbrochen wird, darf der Leaseunterbrechungszeitraum verstreichen, während dessen break und release die einzigen Leasevorgänge sind, die Sie für das Blob ausführen können. Wenn eine Lease erfolgreich unterbrochen wurde, gibt die Antwort das Intervall in Sekunden an, bis eine neue Lease abgerufen werden kann.

Eine lease, die unterbrochen wurde, kann auch freigegeben werden. In diesem Fall kann ein anderer Client die Lease für das Blob sofort abrufen.
x-ms-lease-break-period: N Optional. Version 2012-02-12 und höher. Für einen break-Vorgang ist dies die vorgeschlagene Dauer in Sekunden, die die Lease bis zum Unterbrechen fortgesetzt werden sollte; ein Wert zwischen 0 und 60. Dieser Pausenzeitraum wird nur verwendet, wenn er kürzer ist als die verbleibende Zeit für die Lease. Ist er länger, wird die verbleibende Zeit für die Lease verwendet. Eine neue Lease ist nicht verfügbar, bevor der Pausenzeitraum abgelaufen ist, aber die Lease kann länger als der Pausenzeitraum gehalten werden. Wenn dieser Header bei einem break Vorgang nicht angezeigt wird, wird eine Lease mit fester Dauer nach Ablauf des verbleibenden Leasezeitraums unterbrochen, und eine unendliche Lease bricht sofort.
x-ms-lease-duration: -1 ¦ n seconds Version 2012-02-12 und höher. Nur zulässig und erforderlich für einen acquire Vorgang. Gibt die Dauer der Lease in Sekunden oder als minus eins (-1) für eine nie ablaufende Lease an. Die Dauer einer nicht unendlichen Lease kann zwischen 15 und 60 Sekunden liegen. Eine Leasedauer kann nicht mit renew oder changegeändert werden.
x-ms-proposed-lease-id: <ID> Version 2012-02-12 und höher. Optional für acquireund erforderlich für change. Vorgeschlagene Lease-ID in einem GUID-Zeichenfolgenformat. Blob Storage gibt zurück 400 (Invalid request) , wenn die vorgeschlagene Lease-ID nicht im richtigen Format vorliegt. Eine Liste gültiger Formate finden Sie unter Guid-Konstruktor (String).
Origin Optional. Gibt die Ursprungsdomäne an, von der die Anforderung ausgegeben wird. Wenn dieser Header vorhanden ist, werden CORS (Cross-Origin Resource Sharing)-Header für die Antwort erzeugt. Weitere Informationen finden Sie unter CORS-Unterstützung für die Speicherdienste .
x-ms-client-request-id Optional. Stellt einen vom Client generierten, undurchsichtigen Wert mit einem Zeichenlimit von 1 Kibibyte (KiB) bereit, der beim Konfigurieren der Protokollierung in den Protokollen aufgezeichnet wird. Es wird dringend empfohlen, diesen Header zu verwenden, um clientseitige Aktivitäten mit Anforderungen zu korrelieren, die der Server empfängt. Weitere Informationen finden Sie unter Überwachen Azure Blob Storage.

Dieser Vorgang unterstützt auch die Verwendung bedingter Header 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.

Syntax BESCHREIBUNG
ETag Enthält einen Wert, den Sie verwenden können, um Vorgänge bedingt auszuführen. Weitere Informationen finden Sie unter Angeben von bedingten Headern für Blob Storage-Vorgänge .

Dieser Header wird für Anforderungen zurückgegeben, die für Version 2013-08-15 und höher ausgeführt werden, und der ETag Wert befindet sich in Anführungszeichen.

Diese Lease Blob Eigenschaft wird vom Vorgang nicht geändert.
Last-Modified Datum/Uhrzeit der letzten Änderung des BLOB. Weitere Informationen finden Sie unter Darstellung von Datums-Uhrzeit-Werten in Headern.

Bei jedem Schreibvorgang für das BLOB, einschließlich Updates der Metadaten oder Eigenschaften des BLOBs, wird die Uhrzeit der letzten BLOB-Änderung aktualisiert. Diese Lease Blob Eigenschaft wird vom Vorgang nicht geändert.
x-ms-lease-id: <id> Wenn Sie eine Lease anfordern, gibt Blob Storage eine eindeutige Lease-ID zurück. Während die Lease aktiv ist, müssen Sie die Lease-ID bei jeder Anforderung zum Schreiben in das BLOB sowie bei jeder Anforderung zum Verlängern, Ändern oder Freigeben der Lease einschließen.

Bei einem erfolgreichen Verlängerungsvorgang wird auch die Lease-ID für die aktive Lease zurückgegeben.
x-ms-lease-time: seconds Die geschätzte verbleibende Zeit der Leasedauer in Sekunden. Dieser Header wird nur bei einer erfolgreichen Anforderung zur Unterbrechung der Lease zurückgegeben. Wenn der Umbruch sofort erfolgt, 0 wird zurückgegeben.
x-ms-request-id Dieser Header identifiziert eindeutig die Anforderung, die gestellt wurde, und kann für die Problembehandlung der Anforderung verwendet werden. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge.
x-ms-version Gibt die Version von Blob Storage an, die zum Ausführen der Anforderung verwendet wird. Dieser Header wird für Anforderungen zurückgegeben, die für Version 2009-09-19 und höher erfolgen.
Date Ein UTC-Datums-/Uhrzeitwert, der die Uhrzeit angibt, zu der die Antwort initiiert wurde. Der Dienst generiert diesen Wert.
Access-Control-Allow-Origin Wird zurückgegeben, wenn die Anforderung einen Origin Header enthält und CORS mit einer übereinstimmenden Regel aktiviert ist. Dieser Header gibt den Wert des Origin-Anforderungsheaders im Falle einer Übereinstimmung zurück.
Access-Control-Expose-Headers Wird zurückgegeben, wenn die Anforderung einen Origin Header enthält und CORS mit einer übereinstimmenden Regel aktiviert ist. Gibt die Liste der Antwortheader zurück, die gegenüber dem Client oder Aussteller der Anforderung verfügbar gemacht werden sollen.
Access-Control-Allow-Credentials Wird zurückgegeben, wenn die Anforderung einen Origin Header enthält und CORS mit einer übereinstimmenden Regel aktiviert ist, die nicht alle Ursprünge zulässt. Dieser Header ist auf truefestgelegt.
x-ms-client-request-id Sie können diesen Header verwenden, um Probleme mit Anforderungen und entsprechenden Antworten zu beheben. Der Wert dieses Headers entspricht dem Wert des x-ms-client-request-id Headers, wenn er in der Anforderung vorhanden ist. Der Wert ist höchstens 1.024 sichtbare ASCII-Zeichen. Wenn der x-ms-client-request-id Header in der Anforderung nicht vorhanden ist, ist er in der Antwort nicht vorhanden.

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.

Wichtig

Microsoft empfiehlt die Verwendung Microsoft Entra ID mit verwalteten Identitäten, um Anforderungen an Azure Storage zu autorisieren. Microsoft Entra ID bietet im Vergleich zur Autorisierung mit gemeinsam genutzten Schlüsseln überlegene Sicherheit und Benutzerfreundlichkeit.

Azure Storage unterstützt die Verwendung von Microsoft Entra ID zum Autorisieren von Anforderungen an Blobdaten. Mit Microsoft Entra ID können Sie die rollenbasierte Zugriffssteuerung (Azure RBAC) von Azure verwenden, um einem Sicherheitsprinzipal Berechtigungen zu erteilen. Der Sicherheitsprinzipal kann ein Benutzer, eine Gruppe, ein Anwendungsdienstprinzipal oder eine verwaltete Azure-Identität sein. Der Sicherheitsprinzipal wird von Microsoft Entra ID authentifiziert, um ein OAuth 2.0-Token zurückzugeben. Das Token kann anschließend zum Autorisieren einer Anforderung an den Blob-Dienst verwendet werden.

Weitere Informationen zur Autorisierung mit Microsoft Entra ID finden Sie unter Autorisieren des Zugriffs auf Blobs mit Microsoft Entra ID.

Berechtigungen

Nachfolgend sind die RBAC-Aktion aufgeführt, die für einen Microsoft Entra Benutzer, Gruppe, verwaltete Identität oder Dienstprinzipal erforderlich ist, um den Lease Blob Vorgang aufzurufen, und die integrierte Azure RBAC-Rolle mit den geringsten Berechtigungen, die diese Aktion enthält:

Weitere Informationen zum Zuweisen von Rollen mithilfe von Azure RBAC finden Sie unter Zuweisen einer Azure-Rolle für den Zugriff auf Blobdaten.

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. Der Leasingvertrag wird für die dauer gewährt, die beim Erwerb des Leasingverhältnisses angegeben ist. 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 sie in der Acquire-Anforderung nicht angegeben ist. Der Client kann diese Lease-ID verwenden, um die Lease zu verlängern, seine Lease-ID zu ändern oder die Lease zu freigeben.

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

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

Die folgenden Vorgänge sind für ein leased Blob ohne Angabe der Lease-ID erfolgreich:

Es ist nicht erforderlich, die Lease-ID für GET Vorgänge in einem Blob mit einer aktiven Lease aufzunehmen. 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 blobs darin aktive Leases aufweisen. 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.

Diagramm: Blobleasstatus und Zustandsänderungstrigger

Ein 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 verlängerbar ist. Die im vorherigen Diagramm dargestellten Leaseaktionen führen zu Zustandsübergängen.

Verlängerung status Gesperrte Lease Entsperrte Lease
Leasing für erneuerbare Energien Geleast Abgelaufen
Nicht erneuerbare Mietverträge Breaking Unterbrochen, verfügbar

  • 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 wird 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 verlängern 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, bis 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. 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

Aktion Verfügbar Geleast (A) Unterbrechen (A) Unterbrochen (A) Abgelaufen (A)
Schreiben mit (A) Fehler (412) Geleast (A), Schreibvorgang erfolgreich Unterbrechen (A), Schreibvorgang erfolgreich Fehler (412) Fehler (412)
Schreiben mit (B) Fehler (412) Fehler (409) Fehler (412) Fehler (412) Fehler (412)
Schreiben, keine Lease angegeben Verfügbar, Schreibvorgang erfolgreich Fehler (412) Fehler (412) Verfügbar, Schreibvorgang erfolgreich Verfügbar, Schreibvorgang erfolgreich
Lesen mit (A) Fehler (412) Geleast (A), Lesevorgang erfolgreich Unterbrechen (A), Lesevorgang erfolgreich Fehler (412) Fehler (412)
Lesen mit (B) Fehler (412) Fehler (409) Fehler (409) Fehler (412) Fehler (412)
Lesen, keine Lease angegeben Verfügbar, Lesevorgang erfolgreich Geleast (A), Lesevorgang erfolgreich Unterbrechen (A), Lesevorgang erfolgreich Unterbrochen (A), Lesevorgang erfolgreich Abgelaufen (A), Lesevorgang erfolgreich

Ergebnisse von Leasevorgängen für BLOBs nach Leasestatus

Aktion Verfügbar Geleast (A) Unterbrechen (A) Unterbrochen (A) Abgelaufen (A)
Acquire, keine vorgeschlagene Lease-ID Geleast (X) Fehler (409) Fehler (409) Geleast (X) Geleast (X)
Acquire (A) Geleast (A) Geleast (A), neue Dauer Fehler (409) Geleast (A) Geleast (A)
Acquire (B) Geleast (B) Fehler (409) Fehler (409) Geleast (B) Geleast (B)
Break, Zeitraum=0 Fehler (409) Unterbrochen (A) Unterbrochen (A) Unterbrochen (A) Unterbrochen (A)
Break, Punkt>0 Fehler (409) Unterbrechen (A) Unterbrechen (A) Unterbrochen (A) Unterbrochen (A)
Change, (A) in (B) Fehler (409) Geleast (B) Fehler (409) Fehler (409) Fehler (409)
Change, (B) in (A) Fehler (409) Geleast (A) Fehler (409) Fehler (409) Fehler (409)
Change, (B) in (C) Fehler (409) Fehler (409) Fehler (409) Fehler (409) Fehler (409)
Renew (A) Fehler (409) Geleast (A), Ablaufdauer zurückgesetzt Fehler (409) Fehler (409) Leased(A), wenn das Blob nicht geändert wurde.

Fehler (409), wenn BLOB geändert wurde.
Renew (B) Fehler (409) Fehler (409) Fehler (409) Fehler (409) Fehler (409)
Release (A) Fehler (409) Verfügbar Verfügbar Verfügbar Verfügbar
Release (B) Fehler (409) Fehler (409) Fehler (409) Fehler (409) Fehler (409)
Dauer läuft ab Verfügbar Abgelaufen (A) Unterbrochen (A) Unterbrochen (A) Abgelaufen (A)

Ä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:

Vorgang Speicherkontotyp Abrechnungskategorie
Leaseblob (abrufen, freigeben, erneuern) Premium, Blockblob
Standard „Allgemein v2“		 Weitere Vorgänge
Leaseblob (abrufen, freigeben, erneuern) Standard „Allgemein v1“ Dient zum Lesen von Vorgängen.
Leaseblob (Break, Change) Premium, Blockblob
Standard „Allgemein v2“		 Weitere Vorgänge
Leaseblob (Break, Change) Standard „Allgemein v1“ Schreibvorgänge

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