> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
<snip-a-lot/>
ASSUMPTION:
Poolable component is a component with high instantiation cost and
state thus it can not be used in several threads simultaneously.
> However, the interfaces for the Cocoon pipeline components are broken.
> A Generator should return an XMLSource, a Transformer should return
> an interface that merges XMLSource and ContentHandler, and a
Serializer
> should return a ContentHandler.
Right now Transformers are poolable. They have a state and they are
(supposedly) heavy to new().
If you to change Transformer interface to return only
XMLSource/ContentHandler, all the logic and state Transformer has moves
into this XMLSource.
Thus, XMLSource becomes heavy and Transformer light. Obviously,
Transformer becomes ThreadSafe (which is good) and XMLSource must be
made Poolable (its heavy, it is stateful).
Instead of having one component we ended up with two. Please tell me I
see things wrongly.
<snip what="simple pipeline"/>
> As the ContentHandler.endDocument() is called on each item, they are
> automatically returned to their pools.
Two issues on this one:
1. endDocument might be never be called. I can discard component after
evaluating its cache ID or cache validity.
2. endDocument does not necessarily indicates that I'm done with this
component. Simple example: you are using serializer to serialize xml
fragment 100 times. It would be logical to make a loop:
serialier = lookup();
for(;;){
serializer.setDestination();
serializer.startDocument();
...
serializer.endDocument();
}
<snip/>
> As to timeouts, we can use one policy for the container type. For
> example, Cocoon would benefit from a request based approach.
What if processing continues after sending response?
I.e., after endDocument() on serializer, some work is done in
transformer? Like invoking other serializer?
> Other
> containers may have to use a timeout based approach. Its up to the
> container. Are timeouts sufficient? No. Does it add additional
> complexity for the container? Yes. Does it help the developer?
> absolutely.
There are situations when transaction takes hours to process (I do not
mean DB transaction here). How this will happen?
<snip/>
> > 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.)
>
> See above. The Cocoon pipeline component interfaces are really
> screwed up in this respect. A component's state should be sufficient
> per thread.
Thread can require several components of the same type to do its work.
How this will be handled?
> Anything that is more granular than that needs a
> different treatment.
What could it be?
> > 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.
>
> In Cocoon we have the advantage of knowing that. A pipeline
> component cannot possibly be used past the processing of a request.
Some transformers use instance of serializers to do its work. It could
be looked up on startup and returned on shutdown (to speedup processing
- right now manager.release() is quite expensive operation), and will
not depend on request/response cycles.
Vadim
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
