Sharepoint 计时器作业和对 HTTPRuntime 缓存对象的访问
我计划创建一个 Sharepoint 计时器作业并将其配置为在我们场的所有 Web 前端计算机上运行。
计时器作业将从 SP SQL Server 实例读取数据，并希望将其更新到我们拥有的 2 个 Web FTE 上的 HTTPRuntime 缓存对象中。
问题是，计时器作业是否可以访问 ASP.net 缓存对象，或者因为它们是从 owstimer.exe 运行而不能访问？
如果没有，那么更新 2 个 Web 前端上的缓存项的最佳方法是什么？我应该提到的是，我们当前没有将 IIS 站点配置为单独访问。也就是说，我们有一个 URL 来访问农场，而我们的内容交换机则决定哪台机器获取它。
那么这可能吗？
I am planning to create a Sharepoint Timer Job and configure it to run on all of our farm web front end machines.
The timer job will read data from the SP SQL Server instance and hopefully update it into the HTTPRuntime cache object on the 2 Web FTEs that we have.
The question is this, will the Timer Job have access the ASP.net cache objects or will they not because they're running from owstimer.exe?
If not, what would be the best way of going about updating a cache item on the 2 web front ends? I should mention that we current DO NOT have the IIS sites configured to be acessed seperately. I.e. we have one URL to access the farm and our content switch does the deciding which machine gets it.
So is it even possible?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您不能直接访问缓存。时间作业在与您的网站运行的应用程序池不同的进程中运行。
不过你可以间接地做到这一点。我能想到的一种方法是在您的网站上创建一个简单的 Web 服务，用于侦听计时器作业并更新网站上的缓存。
另一种选择是研究 memcached for .NET，该项目允许您从其他进程访问缓存。
You cannot access the cache directly no. The time jobs are running in a different process than then the application pool your website is running on.
You could do it indirectly though. A way I can think of would be to create a simple web service on your website that listens for your timer job and updates the cache on the website.
Another option would be to look into memcached for .NET, a project that allows you to access the cache from other processes.
如果您想从 WFE 访问它，则不必是 HTTP 运行时缓存，对吧？也许您可以将其存储在列表中？如果这对您来说太重量级、效率低下或听起来很愚蠢，那么您可以通过让您的计时器作业将一个标志填充到 SPWebApplication 的属性哈希表中来向 WFE 发出信号以拉取（或无效）缓存项。该哈希表不能用于存储项目本身，因为它仅限于 DateTime、bool、string、int 等基元。
It doesn't have to be the HTTP runtime cache if you want to access it from the WFEs, right? You could store it in a list perhaps? If that's too heavyweight, inefficient or just sounds silly to you then you could signal the WFEs to pull (or invalidate) the cached item by having your timer job stuff a flag into the SPWebApplication's Properties hashtable. This hashtable couldn't be used to store the item itself as it's limited to primitives like DateTime, bool, string, int etc.