Hi Peter,
I really think that my silly token based mechanism is much lighter and efficient than a child CM would be. Besides, keep in mind that my CM only keeps track of those components that really must be released. Have fun, Paulo Gaspar > -----Original Message----- > From: Peter Donald [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 15, 2002 11:57 PM > To: Avalon Developers List > Subject: Re: [VOTE] RE: ComponentManager interface > > > On Sat, 16 Feb 2002 08:52, Berin Loritsch wrote: > > Now, there are a number of projects who do request/release > semantics with > > the Components in question. That would require alot of rewrite > > Im not proposing you update verything now - I would even say that > you should > not update to use CMs replacement until you hit Cocoon3 or something like > that ;) > > > I *really* want to have a releaseless interface, but with the current > > realities, I am just not seeing how it can be practically done. > > Not possible from practical standpoint if you want 100% of CM users to > migrate without modification. > > > BTW, release() is not Subversion of Control. It is more like a > "locking" > > mechanism. In the end, the Container can do what it wants--i.e. after a > > timeout period automatically reclaim the resource. > > Yep :) I was just waiitng to see what sort of response I would > get. It can be > Subversion and in the past ihas been implemented that way. > > > We can't truly have a request based pattern that behaves in the > assumption > > of one thread per process. In a SEDA based environment, one > request can be > > handled by any number of threads. In that respect, a ThreadLocal Token > > would not be useable--although the Token passed in the Request message > > would work.... > > or alternatively you could retrieve the CM from the request > object and just > use that CM (without needing Tokens etc). So you would go > > public void serviceRequest( MyRequest r ) > { > final ComponentManager cm = r.getComponentManager(); > cm.lookup(...) > } > > and the object that calls the serviceRequest() method would be > responsible > for releasing any resources obtained. You could still use the normal > Composable mechanisms to get static resources if need be but use > the CM from > request to get per-request resources. I am not sure that Cocoon > components > actually have any need for static services though? > > -- > Cheers, > > Pete > > --------------------------------------- > Be nice to your friends. If it weren't > for them, you'd be a complete stranger. > --------------------------------------- > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
