On Thu, 19 Dec 2002 02:50 pm, Berin Loritsch wrote:
> Adam Murdoch wrote:
> > On Wed, 18 Dec 2002 01:18 pm, Berin Loritsch wrote:
> >>There are two major differences. There is a new overall phase
> >>(Transition), which means the component can claim or release any
> >>runtime resources that it will need for processing.
> >
> > Do you mean that initialize() would not be able to look stuff up? Or the
> > component's business methods? Or dispose()?
>
> No, I mean that once a component is in transition, it can be
> brought in and out of service at will. The distinction being that
> we want to offer the opportunity for the component to temporarily
> unload some runtime data that it doesn't need while it is resting.
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?
So when start() is called the component moves from initialise directly to
active state. And similarly, the component moves directly from active to
destroy when stop() is called.
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.
> >>Getting back to the Serviceable interface, we need to realize that now
> >>it is not just making other components available. It is also making
> >>the configuration information available. Below is only one possibility:
> >>
> >>interface ServiceManager
> >>{
> >> Configuration getConfiguration();
> >> void writeConfiguration(Configuration config)
> >> throws ServiceUnavailableException;
> >
> > An alternative to writeConfiguration() or bind( name, config ), would be
> > to return a mutable Configuration.
>
> 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?
> > What goes in the session?
>
> Its something I keep wanting to bring to the table. The problem the
> Session tries to solve is one where pooled components need to keep
> conversational state with its clients. Imagine a system where the
> container only provides a proxy or facade to the client. The container
> will reclaim the component after a period of inactivity and allow it
> to be used by another client. The component needs to maintain its
> information in something called a Session to keep track of where it
> is. Think of it like HttpServlet session objects--but on a much smaller
> scale.
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?
--
Adam
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
