cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Pipeline components and Object Model issues
Date Wed, 15 Aug 2007 08:46:23 GMT
We should first think of the intended behaviour and then think of the
I would expect that the ObjectModel stays the same during one single
request which might end up to be served through a pipeline consisting of
several pipeline components.
If a sub request is started (internal call through one of our protocols)
this gets a new object model which might inherit the values from the
parent or not - this is something we have to decide.

So, technically speaking, we might end up with more than one ObjectModel
per thread when sub requests are involved. The problem now is the
possible sax streaming from a sub request to the parent request where
the ObjectModel has to be changed on-the-fly.
While this direct streaming seems to be very cool in terms of
performance, it created so many problems over the past years, that I
think we should forget about this direct streaming. A sub request writes
its content to a temporary buffer (being this a byte array or a
recording of sax streams) and when its finished, the content is streamed
from this buffer. This allows to change the whole execution context only
twice. But it creates a clean separation between the request and makes
implementing things much easier. It also allows to cache sub requests
completly and directly stream from the cache

Does this make sense?


Grzegorz Kossakowski wrote:
> Hello,
> Joerg Heinicke asked[1] me to provide summary of the issue that Daniel
> raised[2] and outline
> possible solutions so we can discuss them.
> The problem is that Object Model is a signleton object (more precisely,
> with "call" scope defined in
> cocoon-servlet-service-impl) and is passed to the components (pipeline
> components) that are executed
> somehow simultaneously. This can lead to the serious problems like one
> with parameters I described
> here[3] and clarified here[4].
> To elaborate on it further, the situation is similar to the situation
> when thread-unsafe component
> is used in two threads at the same time. You know, it may lead to
> corrupted state and so on. What's
> the classical solution for such problem? Creating two separate instances
> of components assigned to
> each thread respectively.
> I think we should do the same for Object Model. I proposed[5] to create
> new Spring scope (or reuse
> sitemap scope that must be implemented). Actually, such scope does,
> behind-the-scene, what I
> described one paragraph above. It creates new instance (that may inherit
> properties from old one) of
> Object Model when entering pipeline components. Then component is safe
> to modify Object Model
> according to its needs or even pass it to subsequent, internal requets
> (like calling service) and
> can be sure that Object Model contains only data belongs only to the
> current component. What's very
> convenient, Spring scope would be completely transparent to the
> components and even almost
> transparent to the pipeline's implementation. Pipeline's code would have
> to only inform when scope
> is entered and leaved.
> On the other hand, there is a subtle difference between threads ran
> simultaneously and pipeline's
> components ran simultaneously. In latter case, we are in charge of
> component's management and
> execution. That means we know exactly when one or another component is
> executed so we can modify the
> same Object Model instance the way that changes to Object Model
> performed in one component will be
> not visible in another one. Since switching between components occurs on
> every SAX event we would
> have to adjust Object Model on-the-fly for every SAX event and every
> component in a pipeline. This
> solution has been proposed[6] by Daniel that gave more detailed
> description.
> Personally speaking, I really dislike Object Model changing on-the-fly
> idea. It seems rather heavy
> and would be hard to understand in the future. I guess that maintenance
> cost of it would be higher
> than of our custom scope.
> Custom scope proved to be working very well in
> cocoon-servlet-service-impl so I think we should use
> similar concept.
> [1]
> [2]
> [3]
> [4]
> [5]
> [6]

Carsten Ziegeler

View raw message