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