Joerg Heinicke pisze:
On 06.06.2008 12:51, Grzegorz Kossakowski wrote:
E.g. if two threads share the same (inherited) instance of ObjectModel
all nasty side-effects of multi-threading should be expected like
parallel modification and loosing of data consistency kept in OM.
How Cocoon used to solve these kind of problems in the past?
I don't see that much of a problem here - and it always used to be that
way. If it is a distinctive object model or just the request object does
not really make a difference to me. Also in other frameworks where you
only work with request or session objects you have to be aware of
multi-threading.
I agree in general but there is a subtle difference here. I think there are plenty of people that
agree on a statement that one doesn't need to be a Java programmer in order to use Cocoon. There are
many success stories proving that.
In Cocoon you can have complicated scenarios that you introduce only by using standard Cocoon
components and pipelines all glued by sitemap. In such scenarios, when one does not write any line
of custom java code she should be protected from tricky troubles like the one Imran ran into.
The whole issue comes down to finding an answer to crucial question that appeared here already many
times:
How much do we want to inherit from original request (more generally
environment) to subrequests?
The ideal situation would be if we could inherit nothing thus avoiding any tricky problems but such
solution is rather unacceptable because it brings another sort of problems.
Another idea I can think of is to have a clearly and narrowly defined set of things (objects, data)
we want to inherit in subrequests and pay as much attention as we can to assuring that these objects
are protected from any side-effects including running in multi-threaded environments.
At the moment I can think only about two kind of data that we should inherit,
it is:
a) request data (uploaded files, attributes, etc.)
b) ObjectModel (the one defined in cocoon-expression-api that stores for example data coming from
flowscript)
I think the only way we can avoid side-effects is by _cloning_ objects that are inherited so
subrequests do not affect each other and original request (and their environments). Actually, that
not a new idea, see EnvironmentHelper.AbstractCocoonRunnable[1]:
public AbstractCocoonRunnable() {
// Clone the environment stack of the calling thread.
// We'll use it in run() below
Object stack = EnvironmentHelper.environmentStack.get();
if (stack != null) {
this.parentStack = ((EnvironmentStack)stack).clone();
}
}
Therefore I would like to propose introduction of a new scope called "request-inheritable" which
would allow beans (like ObjectModel) to be inherited but by cloning.
What do you think?
Is the multi-threading processing a feature one has to switch on
intentionally?
Yes, but even if you enable it intentionally you still don't have be a Java programmer so all above
applies here as well.
[1]
http://svn.eu.apache.org/viewvc/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/environment/internal/EnvironmentHelper.java?view=markup
--
Grzegorz Kossakowski
