cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thorsten.scherler....@juntadeandalucia.es>
Subject Re: [2.1] AbstractCachingProcessingPipeline and cocoon CLI
Date Tue, 26 Aug 2008 07:59:46 GMT
On Mon, 2008-08-25 at 20:23 -0400, Vadim Gritsenko wrote:
> On Aug 25, 2008, at 6:40 AM, Thorsten Scherler wrote:
...
> Yes, ObjectModelHelper.REQUEST_OBJECT object is always unique. It is  
> actually unique in any environment. And since it is unique, it does  
> not make sense to lock on it at all - lock on unique object serves no  
> purpose :-)

Makes me wonder since HttpServletRequest is always unique as well due to
the headers, so does not violate as well the whole locking?

> You could, for example, have same effect with code:
> 
>      // Avoids NPE, does nothing
>      if (lock == null) lock = new Object();
> 
> 
> To get back to the problem... The original goal of pipeline locking  
> was to prevent separate external requests to start generating cached  
> response for the same resource-intensive resource. In other words, if  
> too external requests both (directly or through aggregation) hit '/ 
> slow/cached/foo' resource, only one request will trigger this  
> pipeline, while another will wait for the first to complete.
> 
> This logic, in turn, had to be augmented to exclude single external  
> request hitting the same slow resource twice due to aggregation (and  
> parallel aggregation), hence locking against top level external  
> request was implemented.
> 

Understand but I am confused due to the above fact that the
HttpServletRequest is as well unique as it is my understanding.

> Now, in situation when CommandLineEnvironment is used from the, ahem,  
> command line, two external requests will not happen. Which means that  
> whole pipeline locking thing is irrelevant and can be omitted  
> completely (like in 'lock = new Object()' snippet above). But, the  
> same CommandLineEnvironment stuff can be used in multi threaded  
> environment which uses the CocoonBean class. So, strictly speaking, in  
> this scenario locking still should be performed against external  
> request object, and not against any RequestWrapper which is unique for  
> each sub-request.

I now are using the url as lock key since as I understand it perfectly
qualifies as lock key. 

The patch is attached to COCOON-2241. As soon you are ok with it I will
commit it. 

Thanks for your patience.

salu2

> 
> Hope now it all makes more sense.
> 
> Regards,
> Vadim
> 
> 
> > In comparison the HttpEnvironment has in the constructor:
> > this.objectModel.put(HTTP_REQUEST_OBJECT, req);
> > where HttpServletRequest req.
> >
> > The uniqueness in both cases are, as I understand, the headers.
> >
> > salu2
> 
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java                      consulting, training and solutions


Mime
View raw message