Responding to DB outages

[madelson]

Responding to DB outages

[madelson]

@jhorbulyk I've considered it but I'm not sure what the API can really do if this happens. It's not like I can cause the code inside the using block to abort. Likely the most we could do is to expose some kind of handle to this state in the return value that callers can check/subscribe to. It's still not perfect from a thread-safety perspective, since you could always lose the lock right after confirming that you have it.

What were you thinking that the API/behavior for this would look like?

In practice, I've never found this to be an issue, and I'm not even 100% sure at this point how much of a network blip will actually take out an inactive SqlConnection. I'm also not sure whether such an asynchronous failure would actually fire the StateChanged event in a background thread vs. only "noticing" the failure when you actually issue another query on that connection.

[jhorbulyk]

I was considering adding a CancellationToken that could be passed into the constructor that could be triggered in the event of a DB connection loss. However, you are correct in that asunchronous failures don't fire the StateChanged events on SqlConnection objects so this becomes a moot point.