BlobRequestOptions.AbsorbConditionalErrorsOnRetry Propriété

public bool? AbsorbConditionalErrorsOnRetry { get; set; }

member this.AbsorbConditionalErrorsOnRetry : Nullable<bool> with get, set

Public Property AbsorbConditionalErrorsOnRetry As Nullable(Of Boolean)

Valeur de propriété

Exemples

using (MemoryStream inputDataStream = new MemoryStream(inputData))
{
    BlobRequestOptions conditionalErrorRequestOptions = new BlobRequestOptions() { AbsorbConditionalErrorsOnRetry = true };

    CloudAppendBlob appendBlob = container.GetAppendBlobReference("appendBlob");
    appendBlob.UploadFromStream(inputDataStream, accessCondition: null, options: conditionalErrorRequestOptions);
}

Remarques

Cette option est utilisée uniquement par l’objet CloudAppendBlob dans les méthodes UploadFrom* , les méthodes AppendFrom* et la classe BlobWriteStream . Par défaut, il est défini sur false. Définissez cette option true sur uniquement pour les scénarios à écriture unique. La définition de true cette option sur dans un scénario multi-writer peut entraîner des données d’objet blob endommagées.

Lors de l’appel de « UploadFrom* » sur un objet blob d’ajout, le client de stockage décompose les données d’entrée en plusieurs blocs de données et charge chaque bloc de données avec une opération « append block ». Normalement, une condition d’accès « IfAppendPositionEqual » est ajoutée à l’opération de bloc d’ajout, de sorte que l’opération de chargement échoue si un autre processus a ajouté des données au milieu de ce flux de données. Toutefois, cela peut entraîner un faux échec dans un cas très spécifique. Si une opération d’ajout échoue avec un délai d’expiration, il est possible que l’opération réussisse sur le service, mais la réponse « réussite » n’a pas été renvoyée au client. Dans ce cas, le client réessaye, puis obtient un échec « ajout de la position non satisfaite ».

La définition de cette valeur true sur entraîne la poursuite de l’opération de chargement lorsqu’elle constate un échec de « la position d’ajout non satisfaite » lors de la nouvelle tentative, en tenant compte de la possibilité ci-dessus. Toutefois, cela perd la protection dans le scénario multi-writer : si plusieurs threads sont chargés sur l’objet blob à la fois et que cette valeur est définie sur true, certaines données peuvent être perdues, car le client pense que les données ont été chargées, alors qu’en fait il s’agissait des données de l’autre processus.

S’applique à