reacting to loss of connection
Lets suppose I have an .NET client application that connects to a WCF service, or perhaps a message queue. During the normal execution of the program it is possible that there might be connection losses or maybe the user has been forced to log off by the administrator, or the administrator sends a message to the app to change and login to another WCF server (e.g. some form of manual load balancing).
The client application would only know about this when any one of many low level methods ties to make a WCF call and it fails.
When such a thing happens I'd like the application and all its windows to somehow be disabled/hidden, for a dialog box / splash window to come up and do a reconnection, and once successful the windows get shown again.
How does one go about doing this? The problem I see is that the code w开发者_JS百科hich first finds out there is a problem is at the lowest level (i.e. maybe as a result of a button click on a dialog window that is on top of main windows). Sort of need the program to be inside out to handle it intuitively. Therefore I am assuming there are some patterns or frameworks that help with this?
Unfortunately there isn't a great way of doing this because the exceptions caused by it are going to start anyplace a WCF call can happen and go upward until something catches them. For the HTTP bindings you know when that will be because WCF only does anything when you make an explicit call, so you could catch any disconnect/timeout exceptions and deal with them appropriately.
For message queues or TCP bindings I think it might get a bit messier, but the tactic is the same. Anytime you're making a WCF call, you'll need to watch for the appropriate exceptions and then the application will have to call some function that can change the UI how you want.
I believe what you're looking for is called "exception handling". Exceptions are the way to get from the bottom to the top.
One of the possible solutions you may apply is you may call some kind of non-transactional method that will return minimal result in a fixed interval. Or if you can get the underlying socket object of the instantiated wcf client; the overhead of checking is not that huge. Though socket objects probably don't have some kind of event that is related to disconnection; you may check only if you try to communicate to the other end but I might be wrong about this.
精彩评论