An AppDomain is analogous to what a process is in WinNT,2K,XP,etc... It's a a logical Process boundary. It loads it's own assemblies just the same way a process loads it's own DLLs. One major difference is that there can be many AppDomains in a Process. The CLR Host manages this. So, in turn, you can have many of the same assembly loaded into a Process, one for each AppDomain that loaded it.
So I think more important in this case is what is the lifetime of an AppDomain. This is usually the life of the process. In general when an EXE is executed, the CLR host sets up one AppDomain and it lives for the life of the process. For ASP.NET...This is different. ASP.NET is a CLR Host and it determines when and how AppDomains are created and destroyed. I don't have my notes/books in front of me right now. I will try and get back with a more detailed answer of how ASP.NET manages AppDomains. But one thing I would caution is that since ASP.NET is controlling the life of these AppDomains, and it often recycles worker processes, I wouldn't always count on it being the SAME exact object for a singleton. If you want this I would suggest not using ASP.NET, Use remoting and override MarshalByRefObject::InitializeLifetimeService and retrun null. -bc On Fri, 31 May 2002 10:04:18 -0500, franklin gray <[EMAIL PROTECTED]> wrote: >The remaining question I have is, What exactly is an AppDomain? > >If my object is created from a Web Service call, is the Web Service the AppDomain? Does this imply that when the Web Service call is finished, the AppDomain is no longer "Live"? > >The reason I ask is because I am using this object like a in memory DB. A Web Service call adds to a collection and another Web Service call removes from the collection. A bunch of these calls is the only connection to the object. > >I have a bug in the system and I haven't had the time yet to figure it out so I am wondering if this is the problem (I don't think it is though). > >-----Original Message----- >From: Bill Conroy [mailto:[EMAIL PROTECTED]] >Sent: Friday, May 31, 2002 8:02 AM >To: [EMAIL PROTECTED] >Subject: Re: [ADVANCED-DOTNET] Singleton pattern > > >This is Bill, and I'm quite sure I'm right. Actually, I'm positive. And >Bajaj is correct also. It's all about the static and setting it means there >will be a root reference for as long as the AppDomain is "live", thus it >will not be GC'd. > >SuppressFinalize only ensures that the Finalize method will NOT be called >for that object. That is it. Nothing more, nothing less. > >-bc > >On Fri, 31 May 2002 11:37:52 +0200, Jonni Faiga <[EMAIL PROTECTED]> wrote: > >>Hi, >>Bills conclusion that SuppressFinalize is not required implies that >>Samir Bajaj's statement regarding has Singleton code in >>http://msdn.microsoft.com/msdnmag/issues/01/07/patterns/patterns.asp >>is that "all you need to do in the C# version is make sure you have a >>live reference to the singleton object for as long as it's needed." is >>incorrect. >> >> >>btw. Any idea why the Rational XDE generated code for a singleton has a >>public constructor? >> >>public class Singleton >>{ >> public void singletonOperation() >> { >> } >> >> public static Singleton getUniqueInstance() >> { >> if(uniqueInstance == null) >> { >> uniqueInstance = new Singleton(); >> } >> return uniqueInstance; >> } >> >> public System.Object getSingletonData() >> { >> return singletonData; >> } >> >> public Singleton() >> { >> } >> >> static Singleton uniqueInstance; >> System.Object singletonData; >>} >> >>You can read messages from the Advanced DOTNET archive, unsubscribe from >Advanced DOTNET, or >>subscribe to other DevelopMentor lists at http://discuss.develop.com. > >You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or >subscribe to other DevelopMentor lists at http://discuss.develop.com. > >You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or >subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
