Re: [RT:A5] What are the _real_ concern areas?

Adam Murdoch wrote:
> 
>>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?

Some components do one thing and do it well.  They don't need sessions 
because the method calls are _atomic_.  One call does it all.  Other 
components need to be pooled because they need to maintain 
conversational state.  The current pooling mechanism requires that the 
client ask for the component, and then explicitly release it later.

For a list of examples, look at every Generator, Transformer, and 
Serializer in the Cocoon application.  (BTW, the Action is an example of 
the atomic strategy).  For those components the issue lies in the fact 
that the components *directly* implement the SAX ContentHandler or 
XMLReader interfaces.

Bottom line is that with the explicit release model, a poorly written 
client will lookup components, but never release them.  That means the 
pool size keeps getting larger and larger and performance and 
scalability drop rather quickly.


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

That is a possibility.  It is reminicent of Stateful Session Beans in 
EJB.  When they are Activated or Passivated, they have a Session object 
that they can store information in.  I think that would be a good 
pattern to follow.

The big thing to experiment with is how quickly should the container 
reclaim the component.  If it is too quick, you run into the equivalent 
of task switch thrashing when you use too many threads.  Anyway it is a 
parameter that the container can play with and set for optimal 
performance for the particular application.


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

I like this approach.  I think it works even better.  But yes, a 
stateful component is a different concern from a stateless component.
I need to work this into a formal proposal--how do you envision the API 
working in this respect?


---------------------------------------------
Introducing NetZero Long Distance
1st month Free!
Sign up today at: www.netzerolongdistance.com