Appfabric 不带 SQLServer 作为配置存储库是一个坏主意吗？
我对 Appfabric 的替换 ASP.NET 会话管理器部分非常感兴趣，并且对分布式缓存管理器有些兴趣。我们不需要它的托管功能。虽然我们内部确实有一个集群 SQLServer，但将其添加为我们的 aspnet/oracle 应用程序的依赖项可能不会被很好地接受。
appfabric 视频建议有一个基于网络的 XML 文件选项，适合小型部署，我们就是这样的（一个 2 节点农场，一个 5 节点农场）。
那么后端没有 SQLServer 的成功案例有吗？对于 Appfabric 而不是 SQLServer，DFS 网络共享是否足够可靠？
I am very interested in the replacment ASP.NET Session Manager portion of Appfabric, and somewhat interested in the distributed cache manager. We don't have a need for its hosting features. While we do have a clustered SQLServer inhouse, adding that as a dependency for our aspnet/oracle application probably would not be well received.
There is a network based XML file option that the appfabric videos suggest is okay for small deployments, which we would be (one 2-node farn, one 5-node farm).
So are there any success stories w/o SQLServer on the backend? Would a DFS network share prove reliable enough for Appfabric instead of SQLServer?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为这正是 AppFabric 团队打算使用 XML 提供程序的情况，即 SQL Server 不可用/不需要的情况。我怀疑是否有任何案例研究已经完成，纯粹是因为 AppFabric 太新了，还没有被编写出来。不过，我不认为使用 XML 提供程序而不是 SQL 提供程序有任何奇怪之处 - 我所能建议的就是尝试一下并看看！如果 XML 提供程序被证明有问题，您可以在以后随时切换到 SQL Server。或者，如果您足够勇敢，您应该能够编写 Oracle 提供程序（尽管 文档 这似乎，嗯，粗略）。
I think this is precisely the situation where the AppFabric team intended the XML provider to be used i.e. where SQL Server is not available/not desired. I doubt that there are any case studies available yet where this has been done, purely because AppFabric is so new that they haven't been written yet. However I don't believe there are any quirks to using the XML provider over the SQL provider - all I can suggest is try it and see! You could always switch over to SQL Server at a later date if the XML provider proves problematic. Or if you're felling brave, you should be able to write an Oracle provider (though the documentation on this seems, um, sketchy).