> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> >
> > Berin,
> >
> > I am 75% for your new CM interface. The problem is point 4.
>
> Am I not a prophet?
:)
> > Assume you have a CM that automatically reclaims all
> > components after each request. That is, for Cocoon, when the
> > request comes in, the CM starts keeping track of what
> > components have been taken out, and when the request has been
> > processed, they are release()'d (or equivalent method).
> >
> > Now introduce pooled components.
> >
> > If more than pool-max components are looked-up during
> > the request you are not performing well, as you empty
> > the pool.
>
> I thought I already did introduce pooled components. It's
> really simple. The GC process for components releases
> them--just like we currently do. The GC process is done
> after the Response is committed.
The scenario was when more than pool-max lookups had been
done before the GC kicks in. Suppose you have a pool-max of 3:
public void handleRequest () {
someMethod ();
someMethod ();
someMethod ();
someMethod ();
}
public void someMethod () {
manager.lookup (ExpensiveButPooledComponent.ROLE);
...
}
With an explicit release() this could be made not to drain the pool.
With GC you can not, unless you set the timeout ridiculously low.
> The GC routine for the container collects any components that
> need to be reclaimed into the pool. As a result we will have
> fewer dangling components than is currently possible. Right
> now, we have the equivalent of C++ memory allocation. The
> onus is on the developer to get it right. The GC brings the
> component into the Java age where GC is the norm. You don't
> have to worry about deleting everything you new in Java, the
> user doesn't have to worry about releasing everything you lookup.
Well that's fine in theory, but in practice you will end up tweaking
and tweaking your GC timeouts and pool sizes, getting bizarre
errors along the way.
> Example:
>
> Proxy that releases the component instance after a timeout of
> 100 ms will wait as a container of nothing until it is either
> GC'd by the JVM or until an interface method has been called.
> In that case, the call blocks until a new Component instance
> is pulled from the pool. The method is then called.
But component state is lost in the "refresh". Meaning that for
a SAX transformer or *any other component with state* you have
screwed up the processing. (So don't allow components with state,
then - well, then they are all ThreadSafe and we do not need
pools.)
The basis of GC is that you can unambiguously tell when an
object is no longer used - when it can not possibly be used.
The speedups we have in pooling is due to explicitly telling
the container that this object can be reclaimed, thus keeping
the object count low.
> I do not want any more work on the client. Let the container
> be smart and the client be dumb.
Agreed! But what you propose is simply too complex to ever work
in practice. There are just too many restrictions on how a
component may behave, too many parameters for the GC policy.
Too much that can go wrong.
Add in different GC policies for different containers and
you end up with making the whole thing more complex instead of
less.
Summary: GC of components...
...means that components may not have state and be pooled.
...means that you always risk draining the pool.
...means a load of GC policy parameters for the client.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
