The reason that your object stays around is because of the static member of in your type of your type is set.(Hope I didn't lose anyone.)
Without that static member you would lose the object in the next GC. The CLR differs from COM in that it doesn't use Reference Counting for lifetime, it has sophisticated algorithms for keeping track of root references to type instances in the CLR. The static member stays in memory for as long as the AppDomain does, which in turn means that your static member stays in memory, thus that is a root reference to your singleton instance, so that is why you see the object staying in memory with this singleton implementation. As an aside, In terms of Rotor and reference counting, this is currently being researched by Chris Sells, et al[1]. -bc [1] http://www.sellsbrothers.com/tools/RotorRefCounting.doc -----Original Message----- From: franklin gray [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 29, 2002 5:52 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] singleton server problem Brent and Bill: You may be right but it isn't what I have been told. I was told that unlike vb 6, objects aren't released when all references are released. Now you got me looking for that thread :-). anyway...My object doesn't seem to disappear and the only references to it are web service calls which of course don't last very long. Is it the fact that a web service is cashed for a while and that is why my objects process isn't finished and the object stays in memory? -----Original Message----- From: Bill Conroy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 29, 2002 4:15 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] singleton server problem I don't believe that SuppressFinalize does what you are thinking here. A call to SuppressFinalize sets a bit on the object that tells the GC not to move this object to the freachable queue from the finalization list. Thus the object will never be finalized when reclaimed. In other words SuppressFinalize merely tells the GC not to call the finalize method just reclaim the memory, and not 'don't reclaim this memory'. It does not pin the object in memory "forever". Something like that could be done with a WeakReference possibly, but this is not needed in this scenario. In this scenario having the static member will keep a root reference to this singleton(once it is created) for the life of this process. And it will never be GC'd. That is all you need. -Bill Conroy -----Original Message----- From: franklin gray [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 29, 2002 4:30 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] singleton server problem so the object will stay in memory after all references have been disposed. That was when you come back to it later, it is still there with the same data. -----Original Message----- From: Bill Conroy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 29, 2002 3:21 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] singleton server problem >> GC.SuppressFinalize(mCurrentUser) Why this call? -bc -----Original Message----- From: franklin gray [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 29, 2002 4:01 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] singleton server problem exactly how do you have you singleton object coded? This is how I do mine. If you do it this way, then there isn't any way to register it as a singleton object that I know of. The system will treat it just like any other object, except it will not garbage collect it. Private Shared mCurrentUser As CurrentUser Public Shared Function Instance() As CurrentUser If mCurrentUser Is Nothing Then mCurrentUser = New CurrentUser() GC.SuppressFinalize(mCurrentUser) End If Instance = mCurrentUser End Function -----Original Message----- From: Manuel Costa [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 29, 2002 11:37 AM To: [EMAIL PROTECTED] Subject: [ADVANCED-DOTNET] singleton server problem Hi, Is there a limit for the number of simultaneous calls to a remote object registered as singleton? I have an application with several servers and several clients per server. After some amount of simultaneous calls to the servers they stop responding, blocking any client call. When a client invokes a method it will stay blocked and if i try to debug at the server side by putting a breakpoint in the called method, nothing will happen. Is there any reasonable explanation for this? Manuel 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. 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.
