Sitecore在發佈媒體項目時如何處理競爭條件？Sitecore媒體項目和競賽條件
場景：
會發生什麼，爲什麼？
其他變化包括： 在媒體項更改安全設置來阻止訪問者下載 媒體項目被刪除訪問並發表了變化
我猜測，在所有這些情況下，下載會中止，但如果是這樣，服務器會發送什麼響應？
這不是一個difinitive答案，我同意瓦特/斯蒂芬約專用的流夥伴。我不知道這樣的系統如何處理這個。
看來，Sitecore的創建爲每個已發佈和訪問修訂新媒體緩存文件，所以HTTP傳輸可以繼續閱讀舊文件，同時系統將寫入新文件。不知道如果禁用緩存（我沒有嘗試禁用緩存），是否/如何工作。否則，嘗試在讀取時寫入可能會被阻止或干擾讀取。
請注意，即使您沒有版本，也會得到新的修訂版本ID。它可能是導致新緩存條目的發佈，而不是新版本的發生。
我沒有一個確切的答案，但Sitecore的/App_Data/MediaCache/下的文件系統上的緩存BLOB資產因此，或許現有的資產仍處於高速緩存。我不確定Sitecore的媒體緩存機制是如何工作的，但我敢打賭，一旦資產完全存在，它就會在新資產的下一個請求中清除/重新緩存。
只是一個猜測。也許反編譯內核以查找處理緩存介質的代碼。
（不是一個真正的答案..只是評論過大的盒子：P）
這是一個非常有趣的問題.. Sitecore的媒體性能是通過它做了很多緩存拷貝到磁盤和在後續請求中從那裏傳遞它（也用於緩存縮略圖等原始縮放副本）。一旦原始項目以某種方式被編輯然後重新發布，文件就會被刷新。
我不確定（並且很好奇）這將如何影響一個大文件，因爲我認爲很多人認爲媒體可能是較小的文件，如圖像或PDF等，用戶只需重新請求，如果破碎，以及如何在項目本身更新時影響當前流式傳輸的文件。我相信很多這方面的工作都是IIS/ASP.NET流媒體，而不是Sitecore本身。
我不知道，如果Sitecore的緩存將保護/針對屏蔽，但這應該是相當足夠簡單，具有較大的媒體文件進行測試。感興趣的結果（如大文件我親自送到已經通過CDN或專用的流合作伙伴完成）
這聽起來最有可能，但我很想知道答案.... –