More reliable cache operations

[JunTaoLuo]

As part of discussions while working on aspnet/Session#99, there were proposals for adding logic in caching to make database operations more reliable. For example, sql database operations may fail intermittently. In this case it may be a good idea to add retry logic and allow users to specify retry policies. This probably needs some more design work.

cc @mikeharder @Tratcher @davidfowl

[sebastienros]

SqlConnection already has this logic internally.
And I think it should be handled by the user, it would not just happen in the cache if it was an issue.

[Tratcher]

When the failures are very provider specific I think there are some things that should be mitigated by the cache wrapper for those providers. E.g. Session is a major consumer of distributed cache and it can't know what different sql errors are retry able. Or Redis errors for that matter.

That said we have changed Session to suppress most errors, disable session for that individual request, and try again for the next request.

[Tratcher]

If SqlConnection has built in support for some of these scenarios, great. So long as it can be configured for the cache.

[muratg]

We'll need to fail silently instead of throwing exceptions.

[natemcmaster]

Per discussion with the team, we decided not to implement retry logic/policies. We may add this in the future if we get more feedback that users want API for this.

For now we will harden Redis and SqlServer cache implementations to silently fail on all operations, and add logging when an expression is suppressed (#238).

[natemcmaster]

We discussed more and will be reverting #238. Suppressing errors isn't a sensible default for some caching scenarios, so we'll need introduce API changes. For now, users who want more reliable operations should wrap cache operations in try/catch.

[muratg]

We'll revisit the design for 2.0.0.

[analogrelay]

Seems like this hasn't gotten traction. Closing as it's not likely to be prioritized moving forward.