2015-10-07 52 views
4

對Azure的Put Blob REST API操作的文件告訴我們,也可以上傳塊BLOB高達64 MB與單個請求。Azure Put Blob操作是否爲原子?

我不知道這樣的操作是否是原子。特別是我需要知道下面的假設是真的還是假的。

  1. 如果兩個或多個客戶端同時投入使用此API指定If-None-Match: *,然後將它們至多有一個會成功的特定不存在的斑點。

  2. 使用該API的Blob看跌永遠不會被部分暴露。它將不存在或存在於包含元數據的整個內容(< 64MB)中。

任何人都可以證實或駁斥這些假設嗎?

+0

一個側面說明:可以上傳更多的是64 MB的一個請求,如果你使用_chunked upload_,在這裏看到我的源代碼https://azureslfileuploader.codeplex.com/SourceControl/latest#tags/ V0.1.9090/AzureSilverlightFileUploaderPlugIn/Uploader.cs爲例。 – 2015-10-07 07:00:25

+0

@IngeHenriksen這不是一個請求上傳,據我可以告訴。看起來你正在上傳塊,在這種情況下,你需要發送至少兩個請求。無論如何,這與我的問題無關。 –

回答

3

我已經從微軟技術支持人員收到確認直接在這些假設都是真

  1. 如果兩個或多個客戶端同時使用此API指定If-None-Match: *放在一個特定的非現有的BLOB ,那麼他們中至多有一個會成功。

  2. 使用該API的Blob看跌永遠不會被部分暴露。它將不存在或存在於包含元數據的整個內容(< 64MB)中。

2

是在Azure的Blob認沽原子操作? 答:沒有。

任何嘗試在完成步驟3之前讀取blob 都會導致HTTP 404(未找到)。

是的,100%保證您會收到404

任何試圖讀取團塊步驟完成後3將 要麼看到整個BLOB內容和元數據,或導致HTTP 404(未找到)在步驟3未成功的情況下。

是,如果操作不徹底存在Blob存儲任何文件

任何企圖把斑點與如果無 - 匹配:*頭的 開始步驟之前2將必須等待,直到步驟3完成後,無論是 成功在這種情況下,必須請求失敗,HTTP 409 (前提失敗)或繼續正常,因爲blob不會 存在。

在我的測試:有沒有等待。

所以,上傳相同的文件名進行第二次嘗試後,通常你會收到一個HTTP/1.1 409指定的BLOB已經存在。 (只是如果你發送的請求與如果 - 無 - 匹配:*頭)

的問題是,如果第一個上傳文件尚未收到第201確認(或唯一的,如果你」重新上傳所有請求),那麼第二個文件將被允許創建資源,即使它是在第一個文件之後啓動的。如果第二個文件比第一個文件短,就會發生這種情況,因爲可能只是第一個(短)請求文件將完成傳輸。

最奇怪的是,當這種情況發生的第一流將繼續正常上傳數據時,最後一個請求發出,直到最後的請求答案是409

我強烈建議你創建一個標溶液來測試你的特定用例,因爲上面描述的情況可能不適合你的應用程序的有效用例。

+0

你肯定的一部分正被放了一滴都看不出來,直到完全上傳?如果是這樣,它就是原子 - 它要麼完全存在,要麼完全不存在。然而,你說*完全不是*是否是原子的答案。混亂。 –

+0

1.是的,我100%肯定2. **「完全不」**部分是因爲最後提到的特殊情況,我的意思是沒有「等待」,如果第一個請求沒有在第二個文件開始上傳之前結束,將存儲第二個文件不是第一個文件。 – JuanK

+0

非常好。你能否解釋爲什麼你100%確定 - 你能鏈接到任何官方文件或其他可靠的來源,這樣說? –