avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Alternative to Serviceable interface?
Date Wed, 05 Nov 2003 15:10:34 GMT
Eric Pugh wrote:

> So maybe part of my attraction to something like the setters/getters method
> is based on either my relatively simple environment, or over simplifing
> things.  And my usage is based on ECM, I am just getting into Merlin.

ECM has a number of issues which I can expose as time goes on.

> In response to Berin's post:
> Typically, maybe always, I just do a lookup, and almost never a release.
> Unless my component is obviously a resource hog, like a caching component, I
> almost never call the release method.  I guess I am counting on the
> container to cleanup after me.  Having to release every component makes me
> think of the bad old days of doing ASP/VB COM programming, where I had to
> explicitly set to null all my objects.  But, in a more complex system, I can
> see how you might have to explicitly release resources.

The fact that you never release your components means you have simple
requirements, and a simple setter would work well for you.

In Merlin and Fortress this is not nearly as big a problem as it is with
ECM.  ECM stores references to that component in a list which grows over time.

The lookup/release issues are more important with ECM than anything else.
However keep in mind that for pooled components it is critical to release the
component when you are done, otherwise the pool grows out of hand.

We would like to move closer to a garbage-collecting policy for pooled
components, or simply remove that possibility.  We simply are not there yet.

> So, in ECM, and maybe Merlin, following your example, if I retrieved an
> email component..  and then logged in, it is possible to have that instance
> of the component actually changed under me?  I assumed that once I did this:
> 	EmailManager myEmailManager = lookup(EmailManager.ROLE); //(or whatever
> lookup is required)

According to the contracts as outlined, that cannot happen until the release
is made.

> that I have a distinct object for the rest of the lifetime of my enclosing
> object?  And, when I destroy the calling object, then all the refereneces to
> myEmailManager will go away, and then ECM/Merlin could toss the component?
> But apprently that doesn't happen..  So, would this be a memory killing
> loop:
> 	while(true){
> 		EmailManager myEmailManager = lookup(EmailManager.ROLE);
> 	}

We would like to make the garbage collection work for us, but you simply cannot
rely on it at this time.  If there are things to clean up, then you may or
may not have that happen.  Not even the JVM provides that guarantee--although
we might as well exploit what we can...

There are other issues in ECM with that loop.  ECM does some "book keeping"
and reference counting to ensure that everything is released so that it can
shut things down in a safe manner.  Both Fortress and Merlin have more advanced
ways of accounting for that so that they know the correct safe order to shut
down components without relying on components to do the releasing themselves.

Even though you don't like to release, it is a good practice to do so in the
dispose() method anyway.

> I guess I assumed that when I left the while loop, the object would go away,
> just like if I did this:
> 	while(true){
> 		EmailManager myEmailManager = new EmailManager();
> 	}

Maybe in Merlin/Fortress, but it never really does go away.  The container has
to account for that component, so it is tracking the component.  In the above
example the new EmailManager() allows the garbage collector to handle things,
and the compiler knows enough that the myEmailManager variable is never used
so the whole content of the loop does not have to be compiled at all.  Therefore
you won't see any build-up of memory because nothing is ever created.

> This is very interesting, because I have recieved reports that Hibernate
> running under the Avalon wrapper I wrote has a memory leak, and this may be
> related to it..  I am going to be doing some profiling over the next week,
> so I am trying to make sure my understanding of Avalon is correct.



"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message