cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: [2.1] AbstractCachingProcessingPipeline and cocoon CLI
Date Thu, 28 Aug 2008 11:44:22 GMT
On Aug 26, 2008, at 3:59 AM, Thorsten Scherler wrote:

> 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?

HttpServletRequest is unique only in context of external request; but  
it is same for multiple sub-requests of single external request.  
Similarly, CommandLineRequest would be unique per single external  
request, but shared across sub-requests.

At the same time, ObjectModelHelper.REQUEST_OBJECT will be always  
unique: it will either be HttpServletRequest/CommandLineRequest for  
top level, or Wrapper for nested requests.



>> 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.

Why not CommandLineRequest?


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

I'd rather use CommandLineRequest; or at least change one line to be:

   this.objectModel.put(CLI_REQUEST_ID, new String(uri));



Vadim


> 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