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