cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Pipeline components and Object Model issues
Date Tue, 14 Aug 2007 16:26:45 GMT
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.

WDYT?

[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74539
[2] http://article.gmane.org/gmane.text.xml.cocoon.devel/74435
[3] http://article.gmane.org/gmane.text.xml.cocoon.devel/74455
[4] http://article.gmane.org/gmane.text.xml.cocoon.devel/74483
[5] http://article.gmane.org/gmane.text.xml.cocoon.devel/74479
[6] http://article.gmane.org/gmane.text.xml.cocoon.devel/74435

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection                ***
*** incessantly so I'll not be able to respond to e-mails                     ***
*** regularly and my work will be somehow irregular.                          ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***

Mime
View raw message