cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Objects inherited in subrequests (was: Re: multithreaded Content Aggregator migration from 2.1 to 2.2)
Date Wed, 11 Jun 2008 21:02:14 GMT
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

Mime
View raw message