Sitecore 在发布媒体项目时如何处理竞争条件？
场景：
会发生什么，为什么？
其他变体包括： 媒体项目上的安全设置更改为阻止访问者下载访问 媒体项目被删除并发布更改
我猜测在所有这些情况下下载都会中止，但如果是这样，服务器会发送什么响应？
【问题讨论】：
标签： sitecore sitecore6 race-condition sitecore-media-library
这不是一个明确的答案，我同意斯蒂芬关于专门的流媒体合作伙伴的看法。我想知道这样的系统如何处理这个问题。
Sitecore 似乎为每个发布和访问的修订创建了一个新的媒体缓存文件，因此 HTTP 传输可以在系统写入新文件时继续读取旧文件。如果禁用缓存（我没有尝试禁用缓存），不确定是否/如何工作。否则，在读取时尝试写入可能会被阻止或干扰读取。
请注意，即使您没有版本，您也会获得一个新的修订 ID。并且可能是发布导致了新的缓存条目，而不是新修订的出现。
【讨论】：
（不是真正的答案.. 只是评论对于盒子来说太大了：P）
这是一个非常有趣的问题。Sitecore 的媒体性能很大程度上是通过将副本缓存到磁盘并在后续请求中从那里交付（也用于缓存原始的缩放副本，例如缩略图等）来实现的。一旦原始项目以某种方式被编辑然后重新发布，文件就会被刷新。
我不确定（并且很感兴趣）这将如何影响大文件，因为我认为很多人认为媒体可能是较小的文件，例如图像或 pdf 等，如果损坏，用户只需重新请求，以及这将如何影响更新项目本身时当前正在流式传输的文件。我确信当时的很多工作是 IIS/ASP.NET 流而不是 Sitecore 本身。
我不确定 Sitecore 的缓存是否会保护/屏蔽这种情况，但这应该非常简单，可以使用更大的媒体文件进行测试。对结果感兴趣（因为我亲自交付的较大文件是由 CDN 或专门的流媒体合作伙伴完成的）
【讨论】：
我没有确切的答案，但 Sitecore 将 blob 资产缓存在 /App_Data/MediaCache/ 下的文件系统上，因此现有资产可能仍在该缓存中。我不确定 Sitecore 的媒体缓存机制是如何工作的，但我敢打赌，一旦资产完全存在，它会在对新资产的下一次请求时清除/重新缓存。
只是猜测。也许反编译内核以找到处理缓存媒体的代码。
【讨论】：