Sitecore媒体项和竞争条件

发布媒体项时，Sitecore如何处理竞争条件

场景：

具有500mb mpg文件（存储为blob）的非版本化媒体项被删除 由网站访问者下载

下载充其量只需要一点时间 一分钟，最坏的情况下可以用小时来衡量（如果他们是在一条线上的话） 低带宽连接）

当用户下载作者时 在媒体项上上载mpg的新版本并发布

发生了什么，为什么

其他变化包括： 媒体项上的安全设置更改为阻止访问者访问 将删除媒体项并发布更改

---

我猜在所有这些情况下，下载都会中止，但如果是这样，服务器会发送什么响应？

我没有确切的答案，但Sitecore会在文件系统上的

/App\u Data/MediaCache/

下缓存blob资产，因此可能现有资产仍在该缓存中。我不确定Sitecore的媒体缓存机制是如何工作的，但我敢打赌，一旦资产完全存在，它会在下一次请求新资产时清除/重新缓存

只是猜测而已。也许反编译内核以找到处理缓存介质的代码。

（这不是一个真正的答案。.只是注释对于框来说太大了：p）

这是一个非常有趣的问题。。Sitecore的媒体性能在很大程度上是通过将副本缓存到磁盘以及在后续请求时从磁盘交付副本来实现的（也用于缓存原始文件的缩放副本，如缩略图等）。以某种方式编辑原始项并重新发布后，将刷新该文件

我不确定（也很好奇）这会如何影响大文件，因为我认为很多人认为媒体可能是较小的文件，如图像或PDF等，如果损坏，用户只需重新请求，以及当项目本身更新时，这会如何影响当前正在传输的文件。我确信在这一点上，很多工作是IIS/ASP.NET流媒体，而不是Sitecore本身

---

我不确定Sitecore的缓存是否能够保护/屏蔽这种情况，但这应该非常简单，可以用更大的媒体文件进行测试。对结果感兴趣（因为我个人交付的较大文件是由CDN或专用流媒体合作伙伴完成的）

这不是一个明确的答案，我同意w/Stephen关于专用流媒体合作伙伴的看法。我想知道这样的系统如何处理这个问题

Sitecore似乎为每个发布和访问的版本创建了一个新的媒体缓存文件，因此HTTP传输可以在系统写入新文件的同时继续读取旧文件。如果禁用缓存（我没有尝试禁用缓存），则不确定是否/如何工作。否则，在读取时尝试写入可能会被阻止或干扰读取

请注意，即使您没有更新版本，也会获得一个新的修订ID。可能是发布导致了新的缓存项，而不是出现新的修订