avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@citi-us.com>
Subject RE: [RT:A5] What are the _real_ concern areas?
Date Thu, 19 Dec 2002 13:56:27 GMT
> From: Adam Murdoch [mailto:adammurdoch@apache.org]
>
> I see.  I think.  When the container moves a component from active to
> transition state, it is saying "don't do anything, because
> the resources you
> are using may be changing"?  And presumably a listener cannot
> be used because
> the resource changes may take a while to complete.
>
> Given this, why should a component move through transition
> state after
> initialize()?  Or before dispose()?  Wouldn't it be better to
> use something
> like suspend() to move the component from active to
> transition, and resume()
> to move it from transition to active?


:)  Really, we should look at merging the two together.  The
Suspend/Resume function is analogous to using the "Pause"
feature on IBM WebSphere, the servlet is not changed and
still has all the resources available to it, WS is merely
witholding any web communications with it.


> This way, both the container and component can opt-in to the
> whole thing.  A
> container doesn't want to support transition state, it never calls
> suspend()/resume().  And if the component doesn't supply a
> suspend()/resume(),  the container can tear it down and spin
> up a new one.

True.


> > But how would the container know when it is safe to save it?
>
> A few options:
>
> - Container's problem.  It can save whenever it wants:
>     - After dispose().
>     - On container shutdown or restart.
>     - On request from management tool.
>     - After every lifecycle method, or state change.
>     - After every config change.
>     - By cycling the component through stop()/start() and
> saving after stop().
>     - Every 2 minutes.
>     - Before dispatching requests to methods, if config is dirty.
>     - 30 seconds after last change.
>     - Never.
>     - Etc.
> - Add config.save(), and make it explicit.
>
> > The bind/write idiom is well understood, and a whole bunch easier to
> > tool.
>
> Can you expand on the "easier to tool" bit?

In the first option you have, the container needs to poll the component
to know when to save the Configuration.  It needs to make sure that there
are no concurrent modifications to the Configuration while it is trying
to save, and it needs to make sure that the Configuration is in a consistent
state.

With the bind/write idiom (which your second option is another form),
the container can make the assumption that while we are saving, no other
modifications are happening to the configuration (we are executing in the
same thread).  Furthermore, the container can assume that the Configuration
is in a consistent state (i.e. there are no half-way added nodes).  The
reason is that the component explicitly stated that it is *done* with the
configuration modifications at the time, and it is safe to record the
information.

Another advantage is that we don't have to waste resources on components
who don't want to save their configuration.



>
> Ok.  Does the container ever notify the component that its
> session state may
> have changed?  Eg, using start()/stop(), or
> suspend()/resume(), or a new
> lifecycle method, or a re*() method, or a listener method.
> Or does the
> component have to look up state in every method?

BTW, I want to get rid of the re*() methods.  A listener
approach works *much* better.

To answer your question, it would be just like how Servlet
sessions are managed.  The container associates the session
with the component, and it invalidates stale sessions.

The component has to merely use it.


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


Mime
View raw message