Suggested Videos
Part 14 - Risks of implementing IExtensibleDataObject interface
Part 15 - Exception handling in WCF
Part 16 - SOAP faults in WCF
This is continuation to Part 16. Please watch Part 16, before proceeding.
An unhandled exception in the WCF service, will cause the communication channel to fault and the session will be lost. Once the communication channel is in faulted state, we cannot use the same instance of the proxy class any more. We will have to create a new instance of the proxy class.
BasicHttpBinding does not have sessions. So when there is an unhandled exception, it only faults the server channel. The client proxy is still OK, because with BasicHttpBinding the channel is not maintaining sessions, and when the client calls again it is not expecting the channel to maintain any session.
WSHttpBinding have secure sessions. So when there is an unhandled exception, it faults the server channel. At this point the existing client proxy is useless as it is also faulted, because with wsHttpBinding the channel is maintaining a secure session, and when the client calls again it expects the channel to maintain the same session. The same session does not exist at the server channel anymore, as the undhandled exception has already torn down the channel and the session along with it.
Part 14 - Risks of implementing IExtensibleDataObject interface
Part 15 - Exception handling in WCF
Part 16 - SOAP faults in WCF
This is continuation to Part 16. Please watch Part 16, before proceeding.
An unhandled exception in the WCF service, will cause the communication channel to fault and the session will be lost. Once the communication channel is in faulted state, we cannot use the same instance of the proxy class any more. We will have to create a new instance of the proxy class.
BasicHttpBinding does not have sessions. So when there is an unhandled exception, it only faults the server channel. The client proxy is still OK, because with BasicHttpBinding the channel is not maintaining sessions, and when the client calls again it is not expecting the channel to maintain any session.
WSHttpBinding have secure sessions. So when there is an unhandled exception, it faults the server channel. At this point the existing client proxy is useless as it is also faulted, because with wsHttpBinding the channel is maintaining a secure session, and when the client calls again it expects the channel to maintain the same session. The same session does not exist at the server channel anymore, as the undhandled exception has already torn down the channel and the session along with it.