针对 Oracle 数据库源的 C# Web 服务有时不可用
我们有一个现有的大型应用程序，其中包含大量数据。我们希望将其用作各种内部编写的 C# Web 应用程序的数据源，因此我们没有更多冗余数据。
我们正在查看的数据不会发生太大变化，因此缓存在大多数情况下都可以正常工作。因此，我们正在针对要在各种内部编写的应用程序中重用的数据编写一个 C# Web 服务。
然而，大约每月一次，Oracle 数据库源不可用。
在 Web 服务中处理此问题的最佳方法是什么，以便依赖该数据的其他应用程序也不会受到干扰？
We have an existing big application which contains a lot of data. We'd like to use it as a datasource for various internally written C# web applications, so we don't have more redundant data.
The data we are looking at doesn't change too much, so caching would work fine most of the time. So we are writing a C# Web Service against the data to be reused in various internally written applications.
However roughly once per month, the Oracle database source is unavailable.
What is the best way to handle this in the web service so that those other applications that rely on that data aren't disrupted also?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
设置复制或故障转移合作伙伴？老实说，这似乎不是需要编写更多代码的工作；这听起来像是需要更多基础设施的工作。我知道 Oracle 许可证很昂贵，但支付开发人员费用来解决不可用问题也很昂贵。
如果您只需使用代码来解决这个问题，那么如果任何定期计划的数据库查询因超时或连接失败类型消息而失败，Web 服务应该简单地保留并返回其缓存数据。在这种情况下，应根据需要保留缓存的数据，直到刷新该数据的调用成功为止。如果没有缓存的数据，您可以吞下错误并且不返回任何内容，或者返回一个错误，说明数据在两个地方都不可用。
Set up replication or failover partners? Honestly, this doesn't seem like a job for more code; it sounds like a job for more infrastructure. I know Oracle licenses are expensive, but so is paying developers to work around unavailability.
If you simply had to solve it with code, then the web services should simply retain and return their cached data if any regularly-scheduled DB query fails with a timeout or connection failed-type message. The cached data should be kept as long as necessary in this circumstance, until a call to refresh that data succeeds. If there is no cached data, you can either swallow the error and return nothing, or return an error stating the data is unavailable from both places.
解决方案是使用不会过期的辅助缓存。
如果第一个（较短的）缓存从数据库成功更新，则辅助缓存将使用最新值进行更新。如果数据库查询失败且第一缓存已过期，则由第二缓存更新第一缓存。所以总有一个二级缓存。
The solution was to use a secondary Cache which doesn't expires.
The secondary cache is updated with the latest values if the first (shorter) cache is successfully updated from the database. If the database querying fails and the first cache has expired, then the first cache is updated by the second cache. So there is always a secondary cache.