Sitecore は、メディア アイテムを公開するときに競合状態をどのように処理しますか?
シナリオ：
何が起こり、なぜですか？
メディア アイテムのセキュリティ設定が変更され、訪問者のダウンロードによるアクセスがブロックされる メディア アイテムが削除され、変更が公開される
これらすべての場合、ダウンロードは中止されると思いますが、もしそうなら、サーバーはどのような応答を送信しますか?
正確な答えはわかりませんが、Sitecore は blob アセットをファイル システムの下にキャッシュ/App_Data/MediaCache/するため、既存のアセットがまだそのキャッシュに残っている可能性があります。Sitecore のメディア キャッシュ メカニズムがどのように機能するかはわかりませんが、アセットが完全にそこにあると、新しいアセットへの次のリクエストでパージ/再キャッシュされるに違いありません。
推測です。おそらく、カーネルを逆コンパイルして、キャッシング メディアを処理するコードを見つけます。
（実際には答えではありません..ボックスにはコメントが大きすぎました:P）
これは非常に興味深い質問です。Sitecore のメディア パフォーマンスは、コピーをディスクにキャッシュし、その後の要求でそこから配信することによって多くのことが行われます (サムネイルなどのオリジナルのスケーリングされたコピーをキャッシュする場合も同様です)。元のアイテムが何らかの方法で編集されてから再公開されると、ファイルはフラッシュされます。
これが大きなファイルにどのように影響するかは不明です（そして興味をそそられます）。多くの人が、メディアはおそらく画像やPDFなどの小さなファイルであり、壊れた場合にユーザーが再リクエストするだけであり、これが現在ファイルにどのように影響するかを想定していると思いますアイテム自体が更新されたときにストリーミングされます。その時点での作業の多くは、Sitecore 自体ではなく、IIS/ASP.NET ストリーミングであると確信しています。
Sitecore のキャッシュがそれを保護/シールドするかどうかはわかりませんが、これはより大きなメディア ファイルでテストするのに十分簡単なはずです。結果に興味があります (私が個人的に配信した大きなファイルは、CDN または専用のストリーミング パートナーによって行われたため)
これは決定的な答えではありません。専用のストリーミング パートナーについては Stephen と同意見です。そのようなシステムがこれをどのように処理するのだろうか。
Sitecore は、発行およびアクセスされたリビジョンごとに新しいメディア キャッシュ ファイルを作成するようです。そのため、システムが新しいファイルを書き込んでいる間、HTTP 送信は古いファイルを読み続けることができます。キャッシュを無効にした場合、それがどのように機能するかはわかりません（キャッシュを無効にしようとはしませんでした）。そうしないと、読み取り中に書き込みを試みると、ブロックされたり、読み取りが妨げられたりする可能性があります。
バージョン管理を行わなくても、新しいリビジョン ID を取得することに注意してください。また、新しいリビジョンの発生ではなく、新しいキャッシュ エントリの原因となる出版物である可能性があります。