> From: Leo Sutic [mailto:[EMAIL PROTECTED]] > > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > > > > There are a couple of details to work out, but there is no > > reason why the YinYang component can't be either freely > > shared between all threads of execution, or freely reclaimed > > by the container. > > Agreed - none. > > Only objection being that enforcing that programming style > seems like a headshot to Avalon usability and thus acceptance.
What do you mean usability/acceptance? I don't see it that way. Could you expound? > I also think that a PerThread (or a PerClient) handling policy is > equivalent to what you have done - with the mapping of role -> > session, you can only have one session per role per client. > If this is not the case, then what are the differences > between PerThread and your proposal? There is a difference in a PerThread vs. a PerClient handling policy. There can be more clients than threads. The Session is associated with each client. > If you try to expand this - so each client can have lookup() multiple > instances of the same role - you end up pooling the sessions. That is a different problem altogether. The session is associated with a role. If your system requires multiple component instances, that is an agreement that has to be made between the container and the client. The example of this of course is Cocoon's Transformer role. However, if the actual instance of the XMLPipeline (the real byproduct of a transformer) is returned instead of a new component instance for each type of transformer then you have a much cleaner architecture. > I also think that most people will end up with all the logic in > a single object they put in the session, and just use the component > as a way of extracting that object from the session and invoke a > method on it. Really? Is that what you do with Servlet sessions? In either case, is that necessarily wrong? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
