avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Mortenson <leifli...@tanukisoftware.com>
Subject [Fortress] Proposed algorithm to fix shutdown order when using a roles file. (Was [VOTE] Is Fortress Good Enough )
Date Fri, 30 May 2003 17:23:33 GMT
Now that the shutdown ordering is working correctly when using meta data,
I have been quite happy with it.  At first I was a little worried about 
the idea
of using "meta" tags that were specific to Avalon.  But after just a couple
days of using them, I am in love with them.  Kudos to whomever first came
up with the idea.
The ROLE/hint method of looking up components without directly using a
selector has also ben working great.

I personally will be using Meta data without any plans to go back.  But I am
a little worried about the fact that Fortress currently is ignoring
dependencies completely when shutting down applications which are
using a roles file and no meta data.   The rats nest of problems this was
causing with my application is what forced me to start looking at using
meta tags in the first place.

In my opinion, Fortress, using a roles file is just plain broken in its
shutdown cycle.  What is the plan long term.   It is really not very 
to migrate your components over to support meta data once you know
how to do it, so Fortress on the whole seems to be quite ready for a
release, but we should probably be warning users that the use of roles
files is not fully supported in the shutdown cycle.  Coming from the ECM
where this just worked.  It took me a while to track down the problems I
was having when my application was shutting down because I was going
on faith that Fortress was honoring its contracts.

To fix this, I was thinking of doing the following.  See what you think:

Whenever a component is about to be initialized, store a reference to
it in a ThreadLocal variable.  When the initialization completes, remove the

Then whenever a component is looked up, we would check to see if
the above ThreadLocal has a component reference.  If so, then we
know that is the component which "depends" on the component being
looked up.   At this point we can verify that the meta information for the
first component contains a reference to the second component in its
dependency list.  If not, add it.

If the looked up component has not yet been initialized, then it will
store any existing reference in the ThreadLocal to the first component
into a local variable.  The component would then repeat the same
cycle as above.  When initialization is complete, the stored reference
to the first component will be placed back into the thread local before

Note that the only time that a reference to a component will be found in
the ThreadLocal  will be if the component is being looked up during
initialization.   If a component looks up another component after it has
been initialized, then the ThreadLocal will be empty.

By following the above algorithm, it should be possible to build up a very
accurate list of dependencies as the application runs.

Currently the shutdown order is being computed before the first
component ever initialized.  But if it was to be recalculated just before
starting the shutdown cycle then the dependencies resolved during
execution could be taken into account and the components would always
be shutdown in the correct order.

Note that because the above algorithm used ThreadLocals, no
synchronization is required, so this should be able to be implemented
very efficiently.

For example:
private static ThreadLocal m_initializingComponent = new ThreadLocal();
public void initializeComponent( ... )
Object parentComponent = m_initializingComponent.get();
m_initializingComponent.set( thisComponent );
m_initializingComponent.set( parentComponent );
Then when looking up a component
public Object lookup( String role )
Object thisComponent = lookupInner( role );
Object parentComponent = m_initializingComponent.get();
if ( parentComponent != null )
parentComponent.addDependency( thisComponent );
return thisComponent

If the above didn't make any sense, let me know and I'll try to explain it
a little better :-)  Its late here and I forced myself to go out and have a
few beers for the first time in a month :-)  Need to do that a little more.



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

View raw message