none
Application Domain not providing fault isolation RRS feed

  • Question

  • Recently I created two app domains and executed some code in context of the other domain.

    Now if some unhandled excption occurs in a separate appdomain ,  the process terminates.

    My question is that why the application domain is not providing me fault isolation???

    Wednesday, January 28, 2009 10:51 AM

Answers

  • Because that's not what it is designed to do.  You could start and run a new thread that executes code loaded into the new AD.  When that thread bombs, you could terminate it and unload the AD without affecting any state in the primary AD.   An AD puts up the wall that prevents the crashing thread from affecting state in the primary AD.  Unloading the AD is required, it was left in an undeterminable state.

    Of course, something really did go wrong and somebody needs to know about it so they can take appropriate action.  That only works in very select circumstances.  Such as those available in server type apps, ASP.NET and SQL Server are the canonical examples.  They have the luxury of accepting multiple web page requests and queries that do not affect each other.  If the request bombs, they can simply send a "sorry, it didn't work" diagnostic back to the client.  Kill the thread, unload the AD, send "sorry" and everything is still hunky-dory.

    That's a luxury that is rarely available in the typical desktop app as run by the default CLR host.  A crashing thread invariably affects the "user experience" negatively.  What ever she set out to do didn't get done.  And won't get done, no matter how often she clicks the button.  And an assembly loaded in an AD very often does affect state in the primary AD.  Long story short, an AD isn't a magic cure for crashing code.

    Hans Passant.
    • Marked as answer by Zhi-Xin Ye Tuesday, February 3, 2009 4:19 AM
    • Marked as answer by Zhi-Xin Ye Tuesday, February 3, 2009 7:05 AM
    Wednesday, January 28, 2009 1:17 PM
    Moderator

All replies

  • Because that's not what it is designed to do.  You could start and run a new thread that executes code loaded into the new AD.  When that thread bombs, you could terminate it and unload the AD without affecting any state in the primary AD.   An AD puts up the wall that prevents the crashing thread from affecting state in the primary AD.  Unloading the AD is required, it was left in an undeterminable state.

    Of course, something really did go wrong and somebody needs to know about it so they can take appropriate action.  That only works in very select circumstances.  Such as those available in server type apps, ASP.NET and SQL Server are the canonical examples.  They have the luxury of accepting multiple web page requests and queries that do not affect each other.  If the request bombs, they can simply send a "sorry, it didn't work" diagnostic back to the client.  Kill the thread, unload the AD, send "sorry" and everything is still hunky-dory.

    That's a luxury that is rarely available in the typical desktop app as run by the default CLR host.  A crashing thread invariably affects the "user experience" negatively.  What ever she set out to do didn't get done.  And won't get done, no matter how often she clicks the button.  And an assembly loaded in an AD very often does affect state in the primary AD.  Long story short, an AD isn't a magic cure for crashing code.

    Hans Passant.
    • Marked as answer by Zhi-Xin Ye Tuesday, February 3, 2009 4:19 AM
    • Marked as answer by Zhi-Xin Ye Tuesday, February 3, 2009 7:05 AM
    Wednesday, January 28, 2009 1:17 PM
    Moderator
  • How would I reload the faulty app domain if the process itself would terminate??

    I do understand that unloading of secondary domain was required but why the primary app domain and the process ?

     

     

    Friday, January 30, 2009 6:12 AM
  • Because you didn't catch the exception.  You cannot replicate this behavior unless you customize the host.
    Hans Passant.
    Friday, January 30, 2009 8:03 AM
    Moderator