avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <adammurd...@apache.org>
Subject Re: [RT:A5] What are the _real_ concern areas?
Date Fri, 20 Dec 2002 02:05:09 GMT
On Thu, 19 Dec 2002 11:56 pm, Berin Loritsch wrote:
> > 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.

Yep, I think that's what we're talking about.

> > > 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.  

No, it doesn't.  The container could poll the config, but doesn't have to.  
Configuration is an interface (as would be the mutable Configuration), so the 
container can hand over any implementation it likes - including one that 
notifies the container when the component makes a change.  The container can 
then apply one of the strategies above to decide when to save.

> 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.

Some of the strategies above guarantee consistency, some don't.

Honestly, I don't particularly care whether the save is explicit or implicit.  
Implicit save was just a random thought.  Having the container do stuff for 
you is always a nice thing, but sometimes it's just not worth the effort. 
Avoiding a save() call doesn't seem to be.  Can always add implicit save 
later anyway.

> > 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.

So a component cannot hang on to conversational state across method calls - it 
all has to go in the session?

Another option is to allow the component to hang on to conversational state 
unless otherwise informed by the container.  Eg using suspend()/resume() (or 
whatever), so that when moving from active to transition state, the component 
must save any conversational state to the session, and when moving from 
transition to active, it must load it from the session.  Maybe a new state 
and pair of lifecycle methods would be better.  You could also remove the 
Session from the ConfigurationManager, and pass it as a parameter to the 
save/load state lifecycle methods instead.

This separates stateful vs stateless and reusable vs non-reuseable, and lets 
both container and component opt-in.  If the container doesn't want to reuse 
a stateful component, it doesn't bother calling the save state method.  And 
if a stateful component doesn't want to be reused, it doesn't bother 
implementing the save/load state methods.


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

View raw message