Adam Murdoch wrote:
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.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?
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
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
