Re: Exchange store event sink

From: Schley Andrew Kutz (sakutz)
Date: 10/03/04 

Date: Sun, 3 Oct 2004 16:49:55 -0500

Dan,

According to Microsoft, GC.Collect() should hardly ever be explicitly
invoked. This is because the .NET GC actually stops all .NET processes
to ask them if they have any garbage they need collected in their
memory.

.NET uses what I believe is called an Ephemereal or Generational GC.
It works on a First In First Out basis. It assumes that objects that
are new in memory will have a shorter lifetime than objects that are
older. You should check out these articles by MS. They really eased
my mind about trusting a GC to do my memory management for me.

GC Part 1 -
http://msdn.microsoft.com/msdnmag/issues/1100/GCI/TOC.ASP?frame=true

GC Part 1 -
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/TOC.ASP?frame=true

GC Optimization -
http://msdn.microsoft.com/library/en-us/dndotnet/html/dotnetgcbasics.asp?frame=true

The

The reason that you never see the Object count decreasing is because a
reference to the object is still held by .NET. Traditional COM+ uses
reference counting but .NET does not. COM+ knows that there is still a
reference to the object so it reflects that. .NET however would let
anyone use the memory the object has if they need to. You see, the
.NET GC will run if the system needs memory, but why should it if the
system is memory happy? It will only slow other .NET processes down
(not by much mind you, it is quite efficient from what I have read).

Also, you need not worry about Exchange invoking the Dispose() method.
This is the beauty of JITA. When you enable that you tell the object
to invoke the Deactivate() method. Even if you do not override this
method in your class, the ServicedComponent superclass that your object
is derived from will invoke the Dispose method, freeing any unmanged
resources. It will then send the object back into the pool or back
into the ether.

On 2004-09-30 09:53:50 -0500, "Dan Deward" <ddeward@msn.com> said:

> Andrew,
>
> I think I've answered my own question. After further reading, it seems the
> increasing object count has to do with garbage collection. I added the call
>
> GC.Collect();
>
> and now the object count remains a 2. Now one last question... Is this the
> right way to handle this?
>
> Thanks,
> Dan
>
>
> "Dan Deward" <ddeward@msn.com> wrote in message
> news:415c1b67$1@news.mcleodusa.net...
>> Andrew,
>>
>>
>>
>> Thank you for pointing me in the right direction. As you may have
> guessed,
>> .NET and COM+ interop are still new to me. Although I'm a veteran COM C++
>> developer, the way you "do things" with .NET and COM+ are different. I've
>> changed my store event sink to support JITA and object pooling using these
>> attributes:
>>
>>
>>
>> namespace EventsSinks
>>
>> {
>>
>> [Guid("DD4CD964-6BEF-4f62-8E8F-34791E05F4F2")]
>>
>> [JustInTimeActivation]
>>
>> public class MySink: ServicedComponent , IExStoreSystemEvents
>>
>> {
>>
>> [AutoComplete]
>>
>> public void OnTimer( string bstrURLItem, int lFlags)
>>
>> {
>>
>> try
>>
>> {
>>
>> if( System.Convert.ToBoolean( lFlags ) )
>>
>> {
>>
>> ProcessTimer( bstrURLItem );
>>
>> }
>>
>> }
>>
>> catch (Exception ex)
>>
>> {
>>
>> throw (ex);
>>
>> }
>>
>>
>>
>> ContextUtil.SetComplete();
>>
>> }
>>
>>
>>
>> protected override bool CanBePooled()
>>
>> {
>>
>> return true;
>>
>> }
>>
>>
>>
>> }
>>
>> }
>>
>>
>>
>> Now the "Activated" counter displayed in the MMC Component Services
> Manager
>> stays at zero, the "Pooled" counter stays at one, however the "Object"
> count
>> continues to increase for each call. So close, but yet so far. Am I
>> missing something obvious? I've read that the client should call Dispose
> to
>> free the object, but in this case my object is being called by the
> Exchange
>> store.
>>
>>
>>
>> Dan
>>
>>
>>
>> "Schley Andrew Kutz" <sakutz@gmail.com> wrote in message
>> news:f4f1f92f.0409291756.508eb887@posting.google.com...
>> [snip]
>>>
>>> Let me know if you need any help. I tackled all of this a few years
>>> ago in .NET and I think I have figured most of it out. It is tricky
>>> at first, but .NET makes things as hard as it makes them easy
>>> sometimes : ) 

--
-- 
-a

Relevant Pages

  • Re: Using Objects from another class to decrease Mem Usage
    ... and then call Dispose *immediately* after you ... IDisposable has no effect on the memory usage if your resources are ... static void Main ... if the GC runs after DoSomething it will not touch the test ...
    (microsoft.public.dotnet.general)
  • Re: Close - No Dispose - Memory Leak?
    ... I expect that in many cases close vs dispose issues are a red herring. ... are usually not the reason for issues with memory or object (connection ... complete N tasks/second and if the load stays below that level it works ... asking other applications to release memory). ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Memory Leak Experts!!!!
    ... > However as soon as app is restored all this memory is swapped back. ... > DataSet Dispose for example doesn't touch tables and rows. ... > free references in due time. ...
    (microsoft.public.dotnet.framework.performance)
  • Re: How much do you leave to VB.Net GARBAGE COLLECTION???
    ... The first time that is checked if it can be destructed is as you invoke the method dispose as that is a member of the object or a member of its parent class. ... Not fysical direct, as one of the goals is that the GC does its work as it is needed in a kind of batch, to get the highest real performance, which is of course not when there is/are more then enough memory and resources available. ... Setting something to nothing means that you set the reference of the object to nothing. ... Dim myObject as New Object ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Bitmap constructor throwing System.Exception
    ... > calling Dispose() repeatedly may actually cause more problems if the users ... the virtual nature of memory on the PPC ... > possibility that long lived objects may be eating up available resources. ... >> problem is caused by the lack of managed memory. ...
    (microsoft.public.dotnet.framework.compactframework)
Loading