> > Basically, you need to be able to store a component State > > (session is a misnomer, I think). In avalon framework, a > > component State *should* be defined by > > Configuration+Parameters+Context+ComponentManager+Lifecycle > > stage, even though this is probably not the case for many > > components as this is not enforced. > > <snip/> > > Not what I was talking about.
oh.... > I am referring to a component in its fully active phase. It > can be used by different clients. However, if the component > communication requires a certain order on calling methods, > then we should store enough information with the client (i.e. > session information) to be able to do its work. ok. Basically you have a lifecycle extension for some components, where there is a specific contract detailing which methods can be called in what order between start() and stop()? > One example is the Generator component. While I think it should > be rethought, I can't do anything about it right now. We do > something along these lines: > > generator.setup(...); > generator.setContentHandler(...); > generator.execute(); > > The setup(...) would bind the necessary information (like the > input stream for the SAX events or request parameters, whatever) > to the session object. The setContentHandler() would bind the > contenthandler to the session. > > that way, if the component is reassigned because other resolving is > taking too long, we can safely resume where we left off. And what you want to do is remove the dependency on the specific order to enable multi-threaded 'setup'? And then generalize this mechanism to all of avalon? Sounds very complex, at little gain in everyday setups (how often does one use SEDA-like architectures?) // thread 1: component.lifecycleMethod1( abitofstate ); // thread 2: component.lifecycleMethod2 ( abitofstate ); // thread 3: component.lifecycleMethod3( abitofstate ); // thread 4: component.doSomeStuff(); where thread 1, 2 and 3 run concurrently so order of calling the methods can not be defined, and thread 4 has to wait for 1, 2 and 3, and it is furthermore possible to also have threads 4, 5, 6 and 7 doing the same as 1, 2, 3 and 4 but for a different request? Still sounds like a transaction to me? - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
